Re: [Qemu-devel] [RFC PATCH 0/2] port network layer onto glib

[Anthony Liguori <anthony@codemonkey.ws>]

Paolo Bonzini <pbonzini@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