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
