Re: [Qemu-devel] [PATCH 06/11] qobject: add QBool type

[Luiz Capitulino <lcapitulino@redhat.com>]

On Mon, 19 Oct 2009 09:17:38 -0500
Anthony Liguori <aliguori@us.ibm.com> wrote:

> Luiz Capitulino wrote:
> > On Sat, 17 Oct 2009 08:36:06 -0500
> > Anthony Liguori <aliguori@us.ibm.com> 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.