[libvirt] [PATCH 2/6] virObject: Introduce virObjectRecursiveLockableNew

[Peter Krempa]

On Mon, Feb 12, 2018 at 11:52:49 +0100, Michal Privoznik wrote:
> Sometimes we need the lock in virObjectLockable to be recursive.
> Because of the nature of pthreads we don't need a special class
> for that - the pthread_* APIs don't distinguish between normal
> and recursive locks.
> 
> Based-on-work-of: John Ferlan <jferlan at redhat.com>
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> ---
>  src/libvirt_private.syms |  1 +
>  src/util/virobject.c     | 22 +++++++++++++++++++---
>  src/util/virobject.h     |  4 ++++
>  3 files changed, 24 insertions(+), 3 deletions(-)
> 
> diff --git a/src/libvirt_private.syms b/src/libvirt_private.syms
> index 3b14d7d15..fcf378105 100644
> --- a/src/libvirt_private.syms
> +++ b/src/libvirt_private.syms
> @@ -2417,6 +2417,7 @@ virObjectListFreeCount;
>  virObjectLock;
>  virObjectLockableNew;
>  virObjectNew;
> +virObjectRecursiveLockableNew;

I think this was NACK'd last time since we did not want to promote usage
of recursive locks in the code. If we provide an object that provides
recursive locking we de-facto promote this usage.

As Pavel stated in his review. Ideally the NWfilter code will be
converted to a less convoluted locking not requiring recursive locks
prior to this so that we don't have to add recursive locking at all.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180212/db68cb44/attachment-0001.sig>