Re: [Qemu-devel] [PATCH 2/2] main: switch qemu_set_fd_handler to g_io_add_watch

[Anthony Liguori <anthony@codemonkey.ws>]

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
>