> 1) rename AioContext to AioSource. > This is my major purpose, which declare it is not a "context" concept, > and GMainContext is the entity represent the thread's activity.
Note that the nested event loops in QEMU are _very_ different from glib nested event loops. In QEMU, nested event loops only run block layer events. In glib, they run all events. That's why you need AioContext. > 2) Break AioSource into FdSource and BhSource. > This make custom code less and simpler, one Gsource for one kind of > job. It is not necessary but IMHO it will make things clear when add > more things into main loop: add a new Gsource sub class, avoid to > always have relationship with AioContext. But this is only complicating things work since users rely on both file- descriptor APIs and bottom half APIs. > >> More reasons: > >> When I thinking how to bind library code to a thread context, it may > >> need to add Context's concept into API of block.c. If I use AioContext, > >> there will need a wrapper API to run the event loop. But If I got > >> glib's GmainContext, things become simple. You already have it because AioContext is a GSource. You do not need to expose the AioContext, except as a GSource. Paolo
