[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/2] main: switch qemu_set_fd_handler to g_io_add_watch
Date: Wed, 07 Sep 2011 09:53:19 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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.


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]