On 07/28/2017 07:07 PM, Pavel Hrdina wrote: > On Fri, Jul 28, 2017 at 12:38:59PM -0400, John Ferlan wrote: >> Rather than overload virObjectUnlock as commit id '77f4593b' has >> done, create a separate virObjectRWUnlock API that will force the >> consumers to make the proper decision regarding unlocking the >> RWLock's. This restores the virObjectUnlock code to using the >> virObjectGetLockableObj as well. >> >> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx> >> --- >> src/conf/virdomainobjlist.c | 36 ++++++++++++++++++------------------ >> src/libvirt_private.syms | 1 + >> src/util/virobject.c | 41 +++++++++++++++++++++++++++-------------- >> src/util/virobject.h | 4 ++++ >> 4 files changed, 50 insertions(+), 32 deletions(-) > > The virObjectLockRead and virObjectLockWrite should be probably renamed > to virObjectRWLockRead and virObjectRWLockWrite for consistency with the > virObjectRWUnlock. > > Reviewed-by: Pavel Hrdina <phrdina@xxxxxxxxxx> This is where I disagree. While you may dislike lock() polymorphism, unlock() is used widely in literature for both mutexes and RW locks. And it makes sense because they are fundamentally the same. I'm not going to NACK this patch only because I find it impolite. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
