From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:44803) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1JVD-0004G3-V9 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:53:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1JVC-0003np-KO for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:53:23 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:39693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1JVC-0003nb-H1 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:53:22 -0400 Received: by yib2 with SMTP id 2so514726yib.4 for ; Wed, 07 Sep 2011 07:53:21 -0700 (PDT) Message-ID: <4E67855F.90004@codemonkey.ws> Date: Wed, 07 Sep 2011 09:53:19 -0500 From: Anthony Liguori 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> In-Reply-To: <4E678267.4020905@redhat.com> 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: Paolo Bonzini Cc: Blue Swirl , Anthony Liguori , qemu-devel@nongnu.org On 09/07/2011 09:40 AM, Paolo Bonzini wrote: > On 09/07/2011 02:42 PM, Anthony Liguori wrote: >> On 09/07/2011 02:03 AM, Paolo Bonzini wrote: >>> On 09/06/2011 05:59 PM, Anthony Liguori wrote: >>>> So it should be possible to add a new Source type that just selects >>>> on a >>>> file descriptor and avoid GIOChannels? >>> >>> I think you still have the problem that glib on Windows waits for >>> HANDLEs, not file descriptors. Also, I'm not sure it's worth it though >>> as long as slirp still does its own fill/poll. >> >> So how do we fix this long term? > > 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? > > 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. Regards, Anthony Liguori > >> We seem to get away with using fds >> today and not HANDLEs, do fds on Windows not work the same with poll as >> they do with select? > > Here is a summary table: > > select socket HANDLEs only > poll does not exist > WaitForMultipleObjects all other HANDLEs > g_poll all other HANDLEs > > We only use select for Windows socket handles today. Everything else is > handled separately (with WaitForMultipleObjects) by > osdep-win32.c/oslib-win32.c. > > Paolo >