qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [PATCH v2 11/11] block: Only poll block la


From: Paolo Bonzini
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v2 11/11] block: Only poll block layer fds in bdrv_aio_poll
Date: Fri, 11 Sep 2015 11:54:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0


On 11/09/2015 11:44, Fam Zheng wrote:
> > > > That would be a step back.  Using GSource is useful because it lets
> > > > you integrate libraries such as GTK+.
> > >
> > > Can we move GTK to a separate GSource thread?
> > 
> > I think that GTK should always run in the main thread, or at least the
> > one running the default main loop / GMainContext.
> 
> Yeah it's basically GMainContext staying in the main thread and
> block/net/chardev I/O put in a new AioContext thread.

Why?  The point of an event loop is that you can multiplex everything on
the same thread.  Unless we have specific needs (e.g. scalability) one
thread is the way to go and keep things simple.

The tool we have for scalability is AioContext + dataplane threads, and
because we _can_ integrate it into the main thread (AioContext is a
GSource) we can write code once for the main thread and for external
dataplane threads.

Using AioContext instead of duplicating the code is great.  Moving SLIRP
to Win32 would get rid of all the duplicated select() code between
aio-win32.c and main-loop.c.  A lot of main-loop.c code can go away
(probably not all because unlike glib we support nanosecond timeouts
with TimerListGroup, but who knows).

However, there is no need to deviate the event loop from the well-known,
standardized glib architecture.

Paolo



reply via email to

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