qemu-devel
[Top][All Lists]
Advanced

[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: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/2] main: switch qemu_set_fd_handler to g_io_add_watch
Date: Fri, 25 Nov 2011 11:46:21 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1

On 11/25/2011 11:24 AM, Fabien Chouteau wrote:
For POSIX, it would be just a call to
glib_select_fill+select+glib_select_poll.  (Everything around
these three would stay in the caller, and the fd_sets would be
passed to os_host_main_loop_wait).

Are you sure we have to use select()?

slirp is fd_set---thus select()---based. iohandler too, though it would likely be simpler to switch it to poll().

I would expect Glib to help us
avoid this kind of os-dependent syscalls.

Long term, yes. However, even with the iothread and other recent refactorings, the QEMU event loop is still in control of everything including glib sources. This is not a problem; the glib event loop is designed to be integrated into other event loops.

Again, Glib should help us skip all these complicated os-dependent
stuff.

To do this, you need to reimplement the various components of the QEMU main loop as GSources. I did it for eventfd (including bottom halves), timerfd and signalfd, but really it was only to learn GSources rather than as something planned for inclusion.

What's missing is iohandlers and qemu_aio_wait/flush are needed too. Either this, or you would need to touch all uses of iohandlers: character devices, the non-raw block protocols (nbd, curl, iscsi, etc.), slirp, and migration.

If you do not want to do this all at once, the first step is to fix the glib main loop for Windows and move things over slowly.

Paolo



reply via email to

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