From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41611) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1K0y-0005xD-VZ for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:26:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1K0s-0000om-2M for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:26:12 -0400 Received: from mx1.redhat.com ([209.132.183.28]:12760) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1K0r-0000oZ-Lj for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:26:05 -0400 Message-ID: <4E678D08.4060108@redhat.com> Date: Wed, 07 Sep 2011 17:26:00 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1314018774-27482-1-git-send-email-aliguori@us.ibm.com> <1314018774-27482-2-git-send-email-aliguori@us.ibm.com> <4E525C5A.8000208@redhat.com> <4E525D87.8010400@codemonkey.ws> <4E525E09.2000107@redhat.com> <4E662EC3.4070603@redhat.com> <4E66436D.6020507@codemonkey.ws> <4E671732.9080108@redhat.com> <4E6766CD.5000807@us.ibm.com> <4E678267.4020905@redhat.com> <4E67855F.90004@codemonkey.ws> In-Reply-To: <4E67855F.90004@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] main: switch qemu_set_fd_handler to g_io_add_watch List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Blue Swirl , Anthony Liguori , qemu-devel@nongnu.org On 09/07/2011 04:53 PM, Anthony Liguori wrote: >> >> Long term, we use GIOChannels for everything, assuming that's possible >> at all. More realistically, we could rewrite socket handling on Windows >> so that we can use g_poll instead of select (don't wait for me doing >> that). > > I assume switching to GIO would resolve all of these issues? Yes. >> Another possibility, the ugliest but also the most realistic, is to >> separate the Windows and POSIX implementations of the main loop more >> sharply. This way glib's main loop can be integrated (differently) into >> both implementations. >> >> In the meanwhile: just do not rely on glib sources on Windows. There >> isn't any large benefit in this patch, and it actually complicates the >> straightforward code in iohandler. Just revert it and #ifdef the glib >> integration in patch 1/2. Since I don't see a 100%-glib main loop >> anytime soon, we are unlikely to lose much. If anybody introduces a >> feature that requires Avahi or GTK+, it won't be supported on Windows. > > My main motivation is unit testing. I want to be able to have device > models only rely on glib main loop primitives such that we can easily > use devices in a simple glib main loop. > > The split main loop approach won't work for that. What if you extract the QEMU main loop to common code, and use it in the tests? Sounds not hard at all with iothread. Paolo