From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mzt73-0000Vy-8x for qemu-devel@nongnu.org; Mon, 19 Oct 2009 10:21:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mzt6x-0000Te-Q6 for qemu-devel@nongnu.org; Mon, 19 Oct 2009 10:21:28 -0400 Received: from [199.232.76.173] (port=58248 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mzt6x-0000Tb-LZ for qemu-devel@nongnu.org; Mon, 19 Oct 2009 10:21:23 -0400 Received: from mx1.redhat.com ([209.132.183.28]:24203) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mzt6x-0002KM-7T for qemu-devel@nongnu.org; Mon, 19 Oct 2009 10:21:23 -0400 Date: Mon, 19 Oct 2009 12:21:14 -0200 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH 06/11] qobject: add QBool type Message-ID: <20091019122114.083a89d0@doriath> In-Reply-To: <4ADC7502.7030903@us.ibm.com> References: <1255786571-3528-1-git-send-email-aliguori@us.ibm.com> <1255786571-3528-7-git-send-email-aliguori@us.ibm.com> <20091018195007.4dbaa599@doriath> <4ADC7502.7030903@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org On Mon, 19 Oct 2009 09:17:38 -0500 Anthony Liguori wrote: > Luiz Capitulino wrote: > > On Sat, 17 Oct 2009 08:36:06 -0500 > > Anthony Liguori wrote: > > > > > >> We currently model as json bool as an int. This works fine on the server side > >> but it means we cannot send back proper bools to the client. Introducing a > >> proper QBool type fixes that. > >> > > > > As we talked earlier today, I think it would be simpler to have QTrue, > > QFalse and QNull as static objects. > > > > We could define that static objects get reference counting disabled, I don't > > see issues in doing that and we get a very simple model. > > > > The big patch bellow does it, only compiled tested though. > > > > If you don't agree with this model, we'll have to allocate QNull objects. > > Actually I would suggest a destroy() method which always resets the > > refcount to 1, but then it will have the concurrency problems on threaded > > applications you've mentioned. > > > > A lot of object systems have dealt with this in various ways. The > trouble with reference counting is usually thread safety. CLR goes to > great lengths to make their objects reference counting thread safe and > it comes at a cost. Python doesn't do anything explicit and it's one of > the reasons that they're stuck with a big lock. > > Since I'd like to expose QObject to client libraries, having a single > static instance would be pretty unfortunate as it would imply a weird > locking semantics. Disabling reference counts for QNull/QBool seems > unfortunate because it suggests that different semantics for certain > objects. > > I think this is a premature optimization. I don't think we need to try > and save the memory here. You can add QNull in your series then.