On 11.11.2016 16:32, Erik Skultety wrote:
The only place we change the @conn object is actually virAdmConnectOpen routine, thus at the moment we don't really need to lock it, given the fact that what we're trying to do here is to change the closeCallback object which is a lockable object itself, so that should be enough to avoid races.
Signed-off-by: Erik Skultety <eskultet@redhat.com> --- src/libvirt-admin.c | 6 ------ 1 file changed, 6 deletions(-)
diff --git a/src/libvirt-admin.c b/src/libvirt-admin.c index 88eef54..1b5fd44 100644 --- a/src/libvirt-admin.c +++ b/src/libvirt-admin.c @@ -465,7 +465,6 @@ int virAdmConnectRegisterCloseCallback(virAdmConnectPtr conn,
virObjectRef(conn);
- virObjectLock(conn); virObjectLock(conn->closeCallback);
virCheckNonNullArgGoto(cb, error); @@ -482,13 +481,11 @@ int virAdmConnectRegisterCloseCallback(virAdmConnectPtr conn, conn->closeCallback->freeCallback = freecb;
virObjectUnlock(conn->closeCallback); - virObjectUnlock(conn);
Well, sometimes we are locking objects just for the sake of lock ordering. But looking into the code I cannot find any other place where they would rely on some specific lock ordering. Michal