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 <jfer...@redhat.com>
>> Signed-off-by: Michal Privoznik <mpriv...@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;
> 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?
libvir-list mailing list