qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 06/11] qobject: add QBool type
Date: Mon, 19 Oct 2009 09:17:38 -0500
User-agent: Thunderbird 2.0.0.23 (X11/20090825)

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

Regards,

Anthony Liguori




reply via email to

[Prev in Thread] Current Thread [Next in Thread]