From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:40368) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGtqY-0004xV-HL for qemu-devel@nongnu.org; Wed, 26 Sep 2012 11:48:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TGtqW-0000Fq-1j for qemu-devel@nongnu.org; Wed, 26 Sep 2012 11:48:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11401) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TGtqV-0000FY-Pu for qemu-devel@nongnu.org; Wed, 26 Sep 2012 11:48:19 -0400 Message-ID: <506323BE.2000504@redhat.com> Date: Wed, 26 Sep 2012 17:48:14 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> <5062F4E4.6070502@redhat.com> <506303E4.6060309@redhat.com> <506311A7.2060906@redhat.com> In-Reply-To: <506311A7.2060906@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: Kevin Wolf Cc: qemu-devel@nongnu.org, Anthony Liguori Il 26/09/2012 16:31, Kevin Wolf ha scritto: >>> In fact, after removing io_flush, I don't really see what makes AIO >>> fd handlers special any more. >> >> Note that while the handlers aren't that special indeed, there is still >> some magic because qemu_aio_wait() bottom halves. > > Do you mean the qemu_bh_poll() call? But the normal main loop does the > same, so I don't see what would be special about it. That's an abstraction leakage, IMHO. After this series the normal main loop does not need anymore to call bottom halves. (Most usage of bottom halves in hw/* is pointless and also falls under the category of leaked abstractions. The other uses could also in principle be called at the wrong time inside monitor commands. Many would be served better by a thread pool if it wasn't for our beloved big lock). >>> qemu_aio_wait() only calls these handlers, but would it do any harm if >>> we called all fd handlers? >> >> Unfortunately yes. You could get re-entrant calls from the monitor >> while a monitor command drains the AIO queue for example. > > Hm, that's true... Who's special here - is it the block layer or the > monitor? I'm not quite sure. If it's the monitor, maybe we should plan > to change that sometime when we have some spare time... ;-) It feels like it's the monitor. But I think in general it is better if as little QEMU infrastructure as possible is used by the block layer, because you end up with impossibly-knotted dependencies. Using things such as GSource to mediate between the block layer and everything else is also better with an eye to libqblock. Also, consider that under Windows there's a big difference: after this series, qemu_aio_wait() only works with EventNotifiers, while qemu_set_fd_handler2 only works with sockets. Networked block drivers are disabled for Windows by these patches, there's really no way to move forward without sacrificing them. Paolo