Re: [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane

[Fam Zheng <famz@redhat.com>]

On Fri, 07/24 09:35, Paolo Bonzini wrote:
> > That way, aio_context_acquire can be dropped by:
> > 
> >     /* @pause_owner_thread: a callback which will be called when _main thread_
> >      * wants exclusively operate on the AioContext, for example with a nested
> >      * aio_poll().
> >      * @resume_owner_thread: a callback which will be called when _main thread_
> >      * has done the exclusive operation.
> >      */
> >     AioContext *aio_context_new(AioContextPauseResumeFn *pause_owner_thread,
> >                                 AioContextPauseResumeFn *resume_owner_thread,
> >                                 void *opaque,
> >                                 Error **errp):
> > 
> >     /* Try to pause the owning thread */
> >     void aio_context_pause(AioContext *ctx, Error **errp);
> > 
> >     /* Try to resume the paused owning thread, cannot fail */
> >     void aio_context_resume(AioContext *ctx);
> > 
> > Then, in iothread.c:
> > 
> >     iothread->ctx = aio_context_new(iothread_pause, iothread_resume,
> >                                     iothread, &local_err);
> > 
> > Where iothread_pause can block the thread with a QemuCond.
> 
> Condition variables don't mix well with recursive mutexes...  Once we
> have bottom halves outside the AioContext lock, however, we could use a
> separate lock for this condition variable.  That would work.

Yes, I thought so.

> 
> I like it, but I still ask myself... what's the difference between
> aio_context_pause/resume and aio_disable/enable_clients? :)  There is
> still state, just in the iothread rather than in the AioContext.

I don't know, maybe this will make aio_context_acquire no longer necessary so
we get virtio-scsi dataplane fixed?

Fam