From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:49785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQdP0-0005KG-UZ for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:16:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TQdOr-0004rp-Bl for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:16:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:43481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TQdOr-0004re-3j for qemu-devel@nongnu.org; Tue, 23 Oct 2012 08:16:01 -0400 Message-ID: <50868A71.4090603@redhat.com> Date: Tue, 23 Oct 2012 14:15:45 +0200 From: Avi Kivity MIME-Version: 1.0 References: <1350897839-29593-1-git-send-email-pingfank@linux.vnet.ibm.com> <1350897839-29593-6-git-send-email-pingfank@linux.vnet.ibm.com> <5085140F.2070603@redhat.com> <508684BE.1080103@redhat.com> <508685C0.60700@redhat.com> <5086862A.1060307@redhat.com> <5086875F.7010108@redhat.com> <50868851.1070806@redhat.com> In-Reply-To: <50868851.1070806@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [patch v4 05/16] memory: introduce ref, unref interface for MemoryRegionOps List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Liu Ping Fan , Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Anthony Liguori , Jan Kiszka On 10/23/2012 02:06 PM, Paolo Bonzini wrote: > Il 23/10/2012 14:02, Avi Kivity ha scritto: >> On 10/23/2012 01:57 PM, Paolo Bonzini wrote: >>> Il 23/10/2012 13:55, Avi Kivity ha scritto: >>>>>> So the stop_machine idea is thrown away? >>>> IIRC I convinced myself that it's just as bad. >>> >>> It may be just as bad, but it is less code (and less pervasive), which >>> makes it less painful. >> >> It saves you the ->ref() and ->unref() calls, which are boilerplate, but >> not too onerous. All of the device model and subsystem threading work >> still needs to be done. > > I'm not worried about saving the ->ref() and ->unref() calls in the > devices. I'm worried about saving it in timers, bottom halves and > whatnot. And also I'm not sure whether all callbacks would have > something to ref/unref as they are implemented now. Hard to say without examples. Something that bothers be with stop_machine is the reliance on cancellation. With timers it's easy, stop_machine, remove the timer, resume. But if you have an aio operation in progress that is not cancellable, you have to wait for that operation to complete. Refcounts handle that well, the object stays until completion, then disappears. -- error compiling committee.c: too many arguments to function