[libvirt] [PATCH v2 0/8] Some virObjectRW* adjustments
Michal Privoznik
mprivozn at redhat.com
Thu Aug 3 15:34:25 UTC 2017
On 08/01/2017 02:05 AM, John Ferlan wrote:
> v1: https://www.redhat.com/archives/libvir-list/2017-July/msg01313.html
>
> Differences from v1:
>
> * Use the names virObjectRWLockRead, virObjectRWLockWrite and
> virObjectRWUnlock
>
> * Instead of an 'int' return, make the virObjectRWLock{Read|Write} be
> void returns just like virObject{Lock|Unlock}
>
> * Separate out the magic number check for the virObjectIsClass consumers
> into its own patch and describe the reasons for usage.
>
> * Apply the same magic number check to virObject{Ref|Unref} separately.
>
> BTW: This looks and works eally nice with what I have for common objects...
>
> John Ferlan (8):
> util: Rename virObjectLockRead to virObjectRWLockRead
> util: Introduce and use virObjectRWLockWrite
> util: Only have virObjectLock handle virObjectLockable
> util: Introduce virObjectGetRWLockableObj
> util: Introduce and use virObjectRWUnlock
> util: Create common error path for invalid object
> util: Add magic number check for object validity
> util: Add object checking for virObject{Ref|Unref}
>
> src/conf/virdomainobjlist.c | 62 ++++++++--------
> src/libvirt_private.syms | 4 +-
> src/util/virobject.c | 169 +++++++++++++++++++++++++++++++++-----------
> src/util/virobject.h | 10 ++-
> 4 files changed, 169 insertions(+), 76 deletions(-)
>
Okay, I've ran some local tests and indeed no tool showed any
misbehaviour when my test binary was mutex-locking an RW lock or
rwlocking a mutex. While I still believe that us, reviewers have to be
careful around locks anyway, rename to virObjectRWLock* can help us
remember if we forget.
ACK series.
Michal
More information about the libvir-list
mailing list