[libvirt] [PATCH 04/13] Add a generic reference counted virObject type

Eric Blake eblake at redhat.com
Mon Jul 16 23:32:13 UTC 2012


On 07/16/2012 09:52 AM, Daniel P. Berrange wrote:

>>> Object references can be manipulated with
>>>
>>>    virObjectRef(conn)
>>>    virObjectUnref(conn)
>>>
>>> The latter returns a true value, if the object has been
>>> freed (ie its ref count hit zero)
>>
>> Should these return the resulting refcount, and/or add a query function
>> that tells the current ref count?  There are some APIs where knowing how
>> many references remain may be useful, rather than just the boolean
>> information of being the last reference.
> 
> My intent was to design an API that encourages/forces safe usage. Since
> the ref count accessors do not require any kind of locking, code that
> has any logic operating on the *current* ref count is quite likely going
> to be broken, as the current ref count can change at any moment. So, IMHO,
> when incrementing/decrementing the ref count, the only safe bit of info
> is whether you just released the last reference, or whether you just
> incremented the first reference. This leads me to believe that virObjectRef
> should be void and virObjectDec should be boolean.

Seems reasonable.  But virConnectClose() is currently documented as
returning the number of remaining references on success; collapsing
things to a boolean means we will be changing our API contract.  I don't
think it will matter in the long run, but it is worth thinking about.

>> Meta-question - do we want to free _virClass objects on clean exit, to
>> keep valgrind analysis happy?  Or are we okay with permanently
>> allocating them and leaking those references on exit?

> 
> If we wanted to free classes, its probably better just to directly
> do ref counting in the virClass struct, and not try to make it
> inherit virObject.

I guess it boils down to a question of whether silencing valgrind
analysis is important.  Maybe the compromise is to leak class objects,
but to add a valgrind suppression rule that silences the analysis of any
memory allocated through the _virClass constructor function.

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120716/100f2236/attachment-0001.sig>


More information about the libvir-list mailing list