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