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