qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC PATCH v2 0/4] port network layer onto glib
Date: Mon, 8 Apr 2013 13:46:16 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Tue, Apr 02, 2013 at 05:49:57PM +0800, liu ping fan wrote:
> On Thu, Mar 28, 2013 at 9:40 PM, Stefan Hajnoczi <address@hidden> wrote:
> > On Thu, Mar 28, 2013 at 09:42:47AM +0100, Paolo Bonzini wrote:
> >> Il 28/03/2013 08:55, Liu Ping Fan ha scritto:
> >> >    3rd. block layer's AioContext will block other AioContexts on the 
> >> > same thread.
> >>
> >> I cannot understand this.
> >
> > The plan is for BlockDriverState to be bound to an AioContext.  That
> > means each thread is set up with one AioContext.  BlockDriverStates that
> > are used in that thread will first be bound to its AioContext.
> >
> > It's not very useful to have multiple AioContext in the same thread.
> >
> But it can be the case that we detach and re-attach the different
> device( AioContext) to the same thread.   I think that the design of
> io_flush is to sync, but for NetClientState, we need something else.
> So if we use AioContext, is it proper to extend readable/writeable
> interface for qemu_aio_set_fd_handler()?

Devices don't have AioContexts, threads do.  When you bind a device to
an AioContext the AioContext already exists independent of the device.

Unfortunately I don't understand your question about io_flush and
readable/writeable qemu_aio_set_fd_handler().

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]