From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57996) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8p4b-00019K-Mf for qemu-devel@nongnu.org; Wed, 28 Sep 2011 04:01:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8p4W-00012R-6V for qemu-devel@nongnu.org; Wed, 28 Sep 2011 04:00:57 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13268) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8p4V-00012M-VT for qemu-devel@nongnu.org; Wed, 28 Sep 2011 04:00:52 -0400 Message-ID: <4E82D42C.2070607@redhat.com> Date: Wed, 28 Sep 2011 10:00:44 +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> <4E81FC29.9090503@redhat.com> <4E823EEE.3030807@codemonkey.ws> <4E82BE4A.3040904@redhat.com> <4E82D238.8040206@siemens.com> In-Reply-To: <4E82D238.8040206@siemens.com> 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: Jan Kiszka Cc: Kevin Wolf , Stefan Hajnoczi , "qemu-devel@nongnu.org" , Avi Kivity On 09/28/2011 09:52 AM, Jan Kiszka wrote: > > You can probably assume that qemu_notify_event (and dually the read in > > the main loop) are resp. write/read memory barriers. Or even full. > > > > If we switch entirely to GSources, it would be nice to use them. But > > since we aren't, and our main loop functionality is quite different from > > glib's (it doesn't rely on abstractions for file descriptors, for > > example), it is just a painful incomplete transition to use glib's idle > > sources to do the exact same thing that is done by bottom halves (which > > are already in our toolbox). > > BTW, I just wondered if there is anything conceptually preventing to > skip this ping pong between AIO thread and main loop and just run the > completion over the former context (under global lock protection of course). Would be a good idea, but it would require some refactoring because tools do not have a global lock. Paolo