From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LMPAB-0005vu-Dq for qemu-devel@nongnu.org; Mon, 12 Jan 2009 10:57:15 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LMPA9-0005tK-Go for qemu-devel@nongnu.org; Mon, 12 Jan 2009 10:57:14 -0500 Received: from [199.232.76.173] (port=40221 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LMPA9-0005sw-8J for qemu-devel@nongnu.org; Mon, 12 Jan 2009 10:57:13 -0500 Received: from mx2.redhat.com ([66.187.237.31]:42667) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LMPA6-000246-Ts for qemu-devel@nongnu.org; Mon, 12 Jan 2009 10:57:11 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n0CFv6EE010172 for ; Mon, 12 Jan 2009 10:57:06 -0500 Message-ID: <496B6850.7090803@redhat.com> Date: Mon, 12 Jan 2009 17:57:04 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Ongoing changes to the displaying code References: <4966ADD4.5090102@codesourcery.com> <4966BB7A.3090303@codemonkey.ws> <4966BEC4.7080903@codemonkey.ws> <4969AC51.8070406@redhat.com> <18795.25313.340698.138719@mariner.uk.xensource.com> In-Reply-To: <18795.25313.340698.138719@mariner.uk.xensource.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Ian Jackson wrote: > Avi Kivity writes ("Re: [Qemu-devel] Ongoing changes to the displaying code"): > >> Instant messaging clients seem to have solved this without resorting to >> multiple processes. >> > > Multiple processes are not a `resort'. And of course an IM client > needs to do a lot less than qemu, and the things that it does do are > much less hairy. > In terms of not shutting down the app when the close button is pressed, a good single process solution exists. I agree that qemu's usage of signals is problematic. Perhaps switching to real-time signals instead of SIGALRM and SIGIO will help. Any other hairy things in qemu? >>> I think that's a better route to go for this sort of thing. If you >>> think it's generally useful, I think it'd also be worthwhile to host >>> within the QEMU project. I just don't think it's the right thing to >>> add into QEMU directly. >>> >> Or it could be done as a separate executable that links to a libqemu.so; >> the standard qemu binary could be implemented the same way. >> > > I'm not sure how well qemu's processing model will fit in with GUI > toolkits. I wouldn't trust Qt and Gtk not to make expectations which > are reasonable in a `general purpose' program but not sensible in > qemu's context. > You would run qemu and the gui in different threads. If the signal problem is resolved, I don't see any other issues. -- error compiling committee.c: too many arguments to function