>> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
