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

>> 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.

> 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.