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

[Michal Privoznik]

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 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.
> 

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