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(a)redhat.com>
> ---
> 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(a)redhat.com>
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