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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list