From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38017) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZJcKL-0007Fp-HN for qemu-devel@nongnu.org; Mon, 27 Jul 2015 02:55:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZJcKK-0002l4-Jq for qemu-devel@nongnu.org; Mon, 27 Jul 2015 02:55:57 -0400 Date: Mon, 27 Jul 2015 14:55:45 +0800 From: Fam Zheng Message-ID: <20150727065545.GA32453@ad.nay.redhat.com> References: <1437633138-29188-1-git-send-email-famz@redhat.com> <55B0A298.4020405@redhat.com> <20150723114336.GA12726@ad.nay.redhat.com> <55B1EACB.9080608@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55B1EACB.9080608@redhat.com> Subject: Re: [Qemu-devel] [RFC PATCH 00/11] aio: Introduce handler type to fix nested aio_poll for dataplane List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org 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