> 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