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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
