[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