On 02/12/2018 01:10 PM, Peter Krempa wrote: > 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@xxxxxxxxxx> >> Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> >> --- >> 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. > I think that is far from happening. And I don't see any difference between virObjectRecursiveLockableNew() and virMutexInitRecursive() in terms of promoting something. Can you shed more light where do you see the difference? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
