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

[Michal Privoznik]

On 02/16/2018 09:34 AM, Pavel Hrdina wrote:
> On Mon, Feb 12, 2018 at 01:16:28PM +0100, Michal Privoznik wrote:
>> 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?
> 
> IMHO the difference is what Peter already wrote, creating new object
> that automatically uses recursive locks makes it easier to use and
> somehow promotes it, because nowadays we are rewriting a lot of code
> to use objects.
> 
> The other argument is that we should avoid recursive locks which
> includes not introducing new code that works with recursive locks.

This can be viewed as rewrite of existing code, not completely new code.

> 
> I know that NWFilter code is complex and removing recursive locks is
> not an easy task, but for the long run I think it's worth it, it will
> make the code cleaner and easier to follow.

Right, that the ideal goal. But as I said it's far from happening. I
think it was you who when trying to fix some issue in NWFilter drew call
graph in NWFilter driver and realized how complicated it is. That's why
I don't see it happening anywhere in near future. Also, if we really
have multiple entry points as Dan mentioned earlier can we really fix
this? I mean there are multiple locks that need to be acquired when
touching a virNWFilterObj. The advantage of reentrant mutex is that we
will not get a dead lock scenario if two functions fight over lock.

Anyway, it's a pity that we are stuck on this patch while reworking the
vir*ObjList code.

> 
> In conclusion, I still stand behind my NACK.

Okay, in that case I'm gonna ACK John's patches. It's very unfortunate
that because of you NACKing this patch we will have to have lock promoting.

Michal