Re: [Qemu-devel] [RFC] Convert AioContext to Gsource sub classes

[Alex Bligh]

On 20 Aug 2013, at 10:59, Wenchao Xia wrote:

>  The main issue here is that components are tightly bind together and
> no clear layer represent the thread and event loop API. Block and hw
> code are inter acting with AioContext, so both GMainContext and
> AioContext are playing the role. I hope to form a library for block,
> So need to pick up one to provide event loop, the choice seems to be:
> 1 GMainContext.
> 2 AioContext.
> 3 Encapsulation, such as GlibQContext.
> 
>  1) and 2) would not be perfect since non standard glib event loop will
> be exposed, 3) will shows a unified interface similar to glib main loop,
> but more code adjust. After some thinking, I guess AioContext is the
> easiest way, which represent the block's own event loop, and give up
> using glib event loop at this level, just add custom API as
> block_iterate(). Briefly, bdrv_read will becomes:
> int bdrv_read(AioContext *ctx, ....);

My 2p: I'd rather lose the glib classes for contexts. Partly because
of the lack of nanosecond support (I verified that glib DOES
play around with the timing values rather than pass them
in an opaque manner), but mostly because (as illustrated
by a different thread today) the interface is a bit opaque towards
the gsource stuff. We could easily have a less general purpose
library which would be simpler and more predictable.

I guess that leaves either (2), or an option (4) - we use our
own encapsulation of AioContext - a sort of AioContext
superclass which would handle the loop stuff but need
not be modelled on block I/O. This could remain modelled on the
glib interface (as AioContext is) if we want.

-- 
Alex Bligh