From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1JJ4-0001o5-J8 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:40:54 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1JJ0-0001Gt-Ig for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:40:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1JJ0-00019N-5i for qemu-devel@nongnu.org; Wed, 07 Sep 2011 10:40:46 -0400 Message-ID: <4E678267.4020905@redhat.com> Date: Wed, 07 Sep 2011 16:40:39 +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> In-Reply-To: <4E6766CD.5000807@us.ibm.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: Anthony Liguori Cc: Blue Swirl , qemu-devel@nongnu.org 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). 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. > 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