Hi folks,
I'd like form a series which remove AioContext's concept and
bind to glib's main loop more closely. Since changed place will be
a bit much so want to know your opinion before real coding:
changes:
**before patch:
typedef struct AioContext {
GSource source;
int walking_handlers;
QemuMutex bh_lock;
struct QEMUBH *first_bh;
int walking_bh;
EventNotifier notifier;
GArray *pollfds;
struct ThreadPool *thread_pool;
} AioContext;
**After patch:
typedef struct BhSource {
GSource source;
QemuMutex bh_lock;
struct QEMUBH *first_bh;
int walking_bh;
} BhSource;
typedef struct FdSource {
GSource source;
int walking_handlers;
EventNotifier notifier;
GArray *pollfds;
struct ThreadPool *thread_pool;
} FdSource;
Benefits:
Original code have a mix of Gsource and GMainContext's concept, we
may want to add wrapper functions around GMainContext's functions, such
as g_main_context_acquire(), g_main_context_prepare(), which brings
extra effort if you want to form a good and clear API layer. With
this changes, all qemu's custom code is attached under Gsource, we
have a clear GMainContext's API layer for event loop, no wrapper is
needed, and the event's loop API is glib's API, a clear layer let
me form a library or adding more things.
before:
qemu's mainloop caller, BH user, fd user
|
AioContext
|
GMainContext
after:
qemu's mainloop caller
| BH user fd user
GmainContext | |
|--------------------------------|--BhSource |
|-------------FdSource
Note:
FdSource could be split more into ThreadSource and FdSource, which
distinguish more. It can be done easily if the change of this series
is online, when found necessary.
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.
--
Best Regards
Wenchao Xia
