Paolo Bonzini <pbonz...@redhat.com> writes: > Il 13/03/2013 06:59, Liu Ping Fan ha scritto: >> These series aim to port network backend onto glib, and >> prepare for moving towards making network layer mutlit-thread. >> The brief of the whole aim and plan is documented on >> http://wiki.qemu.org/Features/network_reentrant >> >> In these series, attach each NetClientState with a GSource >> At the first, I use AioContext instead of GSource, but after discussion, >> I think with GSource, we can integrated with glib more closely. > > Integrating with glib by itself is pointless. What is the *benefit*? > > We have a pretty good idea of how to make multithreaded device models > using AioContext, since we are using it for the block layer and > virtio-blk dataplane. Doing the same work twice, on two different > frameworks, doesn't seem like a very good idea.
Hrm, I had thought on previous threads there was clear agreement that we did not want to use AioContext outside of the block layer. I think we certainly all agree that moving to a thread aware event loop is a necessary step toward multi-threading. I think the only question is whether to use AioContext or glib. AioContext is necessary for the block layer because the block layer still has synchronous I/O. I think we should aim to replace all sync I/O in the long term with coroutine based I/O. That lets us eliminate AioContextes entirely which is nice as the semantics are subtle. I think that's a solid argument for glib over AioContext. The former is well understood, documented, and makes unit testing easier. Did you have a specific concern with using glib vs. AioContext? Is it about reusing code in the block layer where AioContext is required? Regards, Anthony Liguori > > Paolo
