From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8agZ-0005kG-DX for qemu-devel@nongnu.org; Tue, 27 Sep 2011 12:39:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8agY-0004X1-KJ for qemu-devel@nongnu.org; Tue, 27 Sep 2011 12:39:11 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:48956) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8agY-0004Wu-Fm for qemu-devel@nongnu.org; Tue, 27 Sep 2011 12:39:10 -0400 Received: by wwf10 with SMTP id 10so394770wwf.4 for ; Tue, 27 Sep 2011 09:39:09 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <4E81FC29.9090503@redhat.com> Date: Tue, 27 Sep 2011 18:39:05 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1317133583-25212-1-git-send-email-avi@redhat.com> <4E81EB8A.3070202@siemens.com> <4E81F43B.1040708@codemonkey.ws> In-Reply-To: <4E81F43B.1040708@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] event_notifier: move to top-level directory List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Kevin Wolf , Jan Kiszka , qemu-devel@nongnu.org, Avi Kivity , Stefan Hajnoczi On 09/27/2011 06:05 PM, Anthony Liguori wrote: > Actually, for posix-aio, we can just switch to using g_idle_add(). > g_idle_add() uses g_source_attach which is thread safe. g_idle_add() > gives you a thread safe mechanism to defer a piece of work to the > main loop which is really what we want here. For that, a bottom half would also do (apart that I am not sure it is async-safe with TCG). In fact, that would make sense since all of posix_aio_process_queue could become a bottom half. But the problem to be solved here is waking up qemu_aio_wait, and scheduling bottom halves currently wakes up only the vl.c main loop. > This can actually be made to work with sync I/O emulation too by > having another GMainLoop in the sync I/O loop although I thought I > recalled a patch series to remove that stuff. ... which stuff? :) Another GMainLoop in the sync I/O loop is problematic for two reasons: 1) the sync I/O loop does not relinquish the I/O thread mutex, which makes it very different from the outer loop; 2) a nested GMainLoop keeps polling all the file descriptors in the outer loop, which requires you to cope with reentrancy in those monitor commands that flush AIO. Paolo