On Mon, Dec 01, 2008 at 12:09:21AM +0000, Daniel P. Berrange wrote:
This patch fills in the previous stub methods for locking/unlocking internal objects.
With the following methods return a locked object
virDomainFindByID virDomainFindByName virDomainFindByUUID virDomainAssignDef
All the other methods accepting a virDomainObjPtr instance, require that the object first be locked.
For virDomainDefPtr objects, if they are standalone, no locking is required (hence why the Xen driver isn't touched in any of these patches). If they are associated with a virDomainObjPtr though, this parent object must be locked.
The same applies for virNetworkObjPtr, virStoragePoolObjPtr and the virNodeDeviceObjPtr objects & their methods.
okay,
+#ifdef HAVE_PTHREAD_H + +void virNetworkObjLock(virNetworkObjPtr obj) +{ + pthread_mutex_lock(&obj->lock); +} + +void virNetworkObjUnlock(virNetworkObjPtr obj) +{ + pthread_mutex_unlock(&obj->lock); +}
+1 I would just catch the NULL parameter and return there, it's IMHO nicer to just do that in the (un)locking function than in every cleanup path, and I guess Jim agrees (though not 100% sure about his answer :-) Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/