[libvirt] [PATCH 2/3] virobject: Introduce virObjectRWLockable

John Ferlan jferlan at redhat.com
Tue Jul 25 16:26:28 UTC 2017


>> With your suggestion, I'd have to change all virObjectLock() in
>> src/conf/virnetworkobj.c to virObjectLockWrite() (all that lock the hash
>> table, not network object itself).
>>
> 
> Obviously I hadn't completely through everything...
> 
> But perhaps this also proves that under the covers we could have just
> converted virObjectLockable to be a virObjectRWLockable without creating
> the new class. Especially since the former patch 1 has been reverted and
> there's no difference between virObjectLockableNew and
> virObjectRWLockableNew other than which class was used to initialize.
> 
> If they were combined and just the new API to perform the RW lock was
> added, then for paths that want to use read locks:
> 
>    if (!virObjectLockRead(obj))
>       error and fail
> 
>    ...
> 
> IOW: At this point in time - what is the purpose of a separate
> virObjectRWLockableClass?
> 
> 

nm: I needed to keep excavating...  Still I think not using overloaded
Lock/Unlock in order to allow new functions to return a failure status
would be better.

John




More information about the libvir-list mailing list