From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57735) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLb1M-0008N6-2i for qemu-devel@nongnu.org; Tue, 09 Oct 2012 10:43:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLb1I-0001Uu-Vx for qemu-devel@nongnu.org; Tue, 09 Oct 2012 10:42:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53749) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLb1I-0001Uk-Mq for qemu-devel@nongnu.org; Tue, 09 Oct 2012 10:42:52 -0400 Message-ID: <50743792.2060006@redhat.com> Date: Tue, 09 Oct 2012 16:41:22 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1348577763-12920-1-git-send-email-pbonzini@redhat.com> <20121008113932.GB16332@stefanha-thinkpad.redhat.com> <5072CE54.8020208@redhat.com> <20121009090811.GB13775@stefanha-thinkpad.redhat.com> <5073EDB3.3020804@redhat.com> <5073FE3A.1090903@redhat.com> <507401D8.8090203@redhat.com> <507405B5.4060108@redhat.com> <507410BD.6050901@redhat.com> <50741218.90000@redhat.com> <5074171A.2030904@redhat.com> <5074226A.3030907@redhat.com> <507424E5.4060705@redhat.com> <50742B97.2060608@redhat.com> <50743390.3@redhat.com> <50743614.7080805@redhat.com> In-Reply-To: <50743614.7080805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Block I/O outside the QEMU global mutex was "Re: [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: Kevin Wolf , Anthony Liguori , Ping Fan Liu , Stefan Hajnoczi , qemu-devel@nongnu.org, Jan Kiszka On 10/09/2012 04:35 PM, Paolo Bonzini wrote: >> Of course we can violate that and it wouldn't know a thing, but I prefer >> to stick to the established pattern. > > I wasn't suggesting that, just evaluating the different tradeoffs QEMU > could make. Reference counting is complicated because it has to apply > to all objects used as opaques, and we're using things other than the > DeviceState as opaques in many cases. In the last episode we had MemoryRegionOps::ref/unref() to work around that. But yes, it's complicated, and we haven't started to deal with cycles yet. -- error compiling committee.c: too many arguments to function