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

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

 



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@xxxxxxxxxx    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]