From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:34891) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGqj6-0006lx-Na for qemu-devel@nongnu.org; Wed, 26 Sep 2012 08:28:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGqj1-00071X-JS for qemu-devel@nongnu.org; Wed, 26 Sep 2012 08:28:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:10009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGqj1-00071P-Ay for qemu-devel@nongnu.org; Wed, 26 Sep 2012 08:28:23 -0400 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q8QCSMvw028110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 26 Sep 2012 08:28:22 -0400 Message-ID: <5062F4E4.6070502@redhat.com> Date: Wed, 26 Sep 2012 14:28:20 +0200 From: Kevin Wolf MIME-Version: 1.0 References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> In-Reply-To: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org Am 25.09.2012 14:55, schrieb Paolo Bonzini: > This series removes the globals from async.c/aio-posix.c so that > multiple AIO contexts (mini event loops) can be added. Right now, > all block devices still use qemu_bh_new, but switching them to > aio_bh_new would let you associate different files with different > AIO contexts. > > As an added bonus, integration with the glib main loop now happens > via GSource. Each AIO context is a GSource, which means you can > choose either to run it in its own thread (this of course needs > proper locking which is not yet here), or to attach it to the main > thread. > > In this state this is a bit of an academic exercise (though it works > and may even make sense for 1.3), but I think it's an example of the > tiny steps that can lead us towards an upstreamable version of the > data-plane code. Do you have a git tree where I could see what things would look like in the end? I wonder how this relates to my plans of getting rid of qemu_aio_flush() and friends in favour of BlockDriver.bdrv_drain(). In fact, after removing io_flush, I don't really see what makes AIO fd handlers special any more. qemu_aio_wait() only calls these handlers, but would it do any harm if we called all fd handlers? And other than that it's just a small main loop, so I guess it could share code with the real main loop. So, considering this, any reason to let aio.c survive at all? Kevin