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
