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@redhat.com>
Signed-off-by: Michal Privoznik <mprivozn@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;
virObjectRef;
virObjectRWLockableNew;
virObjectRWLockRead;
diff --git a/src/util/virobject.c b/src/util/virobject.c
index b2fc63aec..1d82e826b 100644
--- a/src/util/virobject.c
+++ b/src/util/virobject.c
@@ -257,8 +257,9 @@ virObjectNew(virClassPtr klass)
}
-void *
-virObjectLockableNew(virClassPtr klass)
+static void *
+virObjectLockableNewInternal(virClassPtr klass,
+ bool recursive)
{
virObjectLockablePtr obj;
@@ -272,7 +273,8 @@ virObjectLockableNew(virClassPtr klass)
if (!(obj = virObjectNew(klass)))
return NULL;
- if (virMutexInit(&obj->lock) < 0) {
+ if ((!recursive && virMutexInit(&obj->lock) < 0) ||
+ (recursive && virMutexInitRecursive(&obj->lock) < 0)) {
virReportSystemError(errno, "%s",
_("Unable to initialize mutex"));
virObjectUnref(obj);
@@ -283,6 +285,20 @@ virObjectLockableNew(virClassPtr klass)
}
+void *
+virObjectLockableNew(virClassPtr klass)
+{
+ return virObjectLockableNewInternal(klass, false);
+}
+
+
+void *
+virObjectRecursiveLockableNew(virClassPtr klass)
+{
+ return virObjectLockableNewInternal(klass, true);
+}
+
+
void *
virObjectRWLockableNew(virClassPtr klass)
{
diff --git a/src/util/virobject.h b/src/util/virobject.h
index ac6cf22f9..367d505ae 100644
--- a/src/util/virobject.h
+++ b/src/util/virobject.h
@@ -116,6 +116,10 @@ void *
virObjectLockableNew(virClassPtr klass)
ATTRIBUTE_NONNULL(1);
+void *
+virObjectRecursiveLockableNew(virClassPtr klass)
+ ATTRIBUTE_NONNULL(1);
+
void *
virObjectRWLockableNew(virClassPtr klass)
ATTRIBUTE_NONNULL(1);
--
2.13.6
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > Signed-off-by: Michal Privoznik <mprivozn@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. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> >> Signed-off-by: Michal Privoznik <mprivozn@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> > >> Signed-off-by: Michal Privoznik <mprivozn@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. 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. In conclusion, I still stand behind my NACK. Pavel > > Michal > > -- > libvir-list mailing list > libvir-list@redhat.com > https://www.redhat.com/mailman/listinfo/libvir-list -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@redhat.com> >>>> Signed-off-by: Michal Privoznik <mprivozn@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote: > 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@redhat.com> > >>>> Signed-off-by: Michal Privoznik <mprivozn@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 [...] > 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. So and why can't we keep the NWfilter code as-is until the locking is sanitized first? It is working so I don't see a reason to try to rewrite it to objects if it is not trivially possible. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/16/2018 10:08 AM, Peter Krempa wrote: > On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote: >> 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@redhat.com> >>>>>> Signed-off-by: Michal Privoznik <mprivozn@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 > > [...] > >> 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. > > So and why can't we keep the NWfilter code as-is until the locking is > sanitized first? It is working so I don't see a reason to try to rewrite > it to objects if it is not trivially possible. > Well, I find it somewhat disappointing. The patches that John and I proposed make things better. But because they don't make it 100% better they are NACKed. But I can live with having two different implementations for vir*ObjList if that's what we want. Or if it's better than having either John's or mines patches merged. I think otherwise though. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/16/2018 04:47 AM, Michal Privoznik wrote: > On 02/16/2018 10:08 AM, Peter Krempa wrote: >> On Fri, Feb 16, 2018 at 09:52:53 +0100, Michal Privoznik wrote: >>> 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@redhat.com> >>>>>>> Signed-off-by: Michal Privoznik <mprivozn@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 >> >> [...] >> >>> 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. >> >> So and why can't we keep the NWfilter code as-is until the locking is >> sanitized first? It is working so I don't see a reason to try to rewrite >> it to objects if it is not trivially possible. >> That assumes some day locks will be sanitized or the nwfilter code will be rewritten. The chances of that happening are slim and nil AFAICT. Perhaps the "best" one could do is keep a cache of already locked objects to use for the lookup code rather than just using the "normal" find object in list logic. That way the code doesn't need to have recursive locks. Given that change in the code is feared - what chance does making any change at being successful? At least the changes we're discussing now allow the code to use existing mechanisms for object list and object mgmt. Keeping the nwfilter code as-is is an option, but to say it's working would seem to gloss over the fact that it's using recursive locks that can be used for write, but aren't "yet" unless someone removes the nwfilter driver, filter update, and callback locks in the define, undefine, and reload paths that keep any chance of an update in a single threaded path. > > Well, I find it somewhat disappointing. The patches that John and I > proposed make things better. But because they don't make it 100% better > they are NACKed. But I can live with having two different > implementations for vir*ObjList if that's what we want. Or if it's > better than having either John's or mines patches merged. I think > otherwise though. > At some point in time using virObjectLockable for managing refs, locks, and memory reclamation was deemed making things better. At some point in libvirt history virMutexInitRecursive was deemed to be OK, but now it's not for the purpose of using virObject* code for nwfilters. Eventually RWReadLocks came along which by nature allow the same thread to hold multiple concurrent read locks as long as the same number of matching unlocks is done. So it seemed reasonable to me to have virNWFilterObj use an RW lock, but in doing so the problem is we "know" it's a read lock, so in order to update the object getting a write lock is the "normal" thing to do. That meant promotion because it's undefined what happens if you have a read lock and you get a write lock. So maybe we "use" that knowledge that the define, undefine, and reload paths are single threaded and either avoid the promotion altogether or heavily document the NWFilterObj promotion to indicate the issue behind doing this promotion without the additional protection so that no one copies the logic. Or we do nothing because things "work". John -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 02/12/2018 05:52 AM, 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@redhat.com>
> Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
> ---
> src/libvirt_private.syms | 1 +
> src/util/virobject.c | 22 +++++++++++++++++++---
> src/util/virobject.h | 4 ++++
> 3 files changed, 24 insertions(+), 3 deletions(-)
>
Adding recursive locks to virObject* was already rejected once before:
Patch:
https://www.redhat.com/archives/libvir-list/2017-May/msg01183.html
Responses:
https://www.redhat.com/archives/libvir-list/2017-May/msg01212.html
https://www.redhat.com/archives/libvir-list/2017-May/msg01215.html
When you added RWLock's in commit '77f4593b' (afterwards) - I began
thinking - hey the NWFilter code could use those. So I essentially
ditched the effort that used trylock:
https://www.redhat.com/archives/libvir-list/2017-July/msg00673.html
in favor of one that used RWLocks:
https://www.redhat.com/archives/libvir-list/2017-October/msg00264.html
Unlike previous alterations to driver/vir*objlist code - I found that I
needed to change the vir*Obj before changing the vir*ObjList, although I
have forgotten why at this point. Eventually I also discovered why
avocado test was causing libvirtd to go defunct (as noted in the cover
of the v3). That was due to the way the test restarts libvirtd prior to
each run and an unrelated issue in nodedev w/r/t initialization, see:
https://www.redhat.com/archives/libvir-list/2017-December/msg00312.html
John
> 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;
> virObjectRef;
> virObjectRWLockableNew;
> virObjectRWLockRead;
> diff --git a/src/util/virobject.c b/src/util/virobject.c
> index b2fc63aec..1d82e826b 100644
> --- a/src/util/virobject.c
> +++ b/src/util/virobject.c
> @@ -257,8 +257,9 @@ virObjectNew(virClassPtr klass)
> }
>
>
> -void *
> -virObjectLockableNew(virClassPtr klass)
> +static void *
> +virObjectLockableNewInternal(virClassPtr klass,
> + bool recursive)
> {
> virObjectLockablePtr obj;
>
> @@ -272,7 +273,8 @@ virObjectLockableNew(virClassPtr klass)
> if (!(obj = virObjectNew(klass)))
> return NULL;
>
> - if (virMutexInit(&obj->lock) < 0) {
> + if ((!recursive && virMutexInit(&obj->lock) < 0) ||
> + (recursive && virMutexInitRecursive(&obj->lock) < 0)) {
> virReportSystemError(errno, "%s",
> _("Unable to initialize mutex"));
> virObjectUnref(obj);
> @@ -283,6 +285,20 @@ virObjectLockableNew(virClassPtr klass)
> }
>
>
> +void *
> +virObjectLockableNew(virClassPtr klass)
> +{
> + return virObjectLockableNewInternal(klass, false);
> +}
> +
> +
> +void *
> +virObjectRecursiveLockableNew(virClassPtr klass)
> +{
> + return virObjectLockableNewInternal(klass, true);
> +}
> +
> +
> void *
> virObjectRWLockableNew(virClassPtr klass)
> {
> diff --git a/src/util/virobject.h b/src/util/virobject.h
> index ac6cf22f9..367d505ae 100644
> --- a/src/util/virobject.h
> +++ b/src/util/virobject.h
> @@ -116,6 +116,10 @@ void *
> virObjectLockableNew(virClassPtr klass)
> ATTRIBUTE_NONNULL(1);
>
> +void *
> +virObjectRecursiveLockableNew(virClassPtr klass)
> + ATTRIBUTE_NONNULL(1);
> +
> void *
> virObjectRWLockableNew(virClassPtr klass)
> ATTRIBUTE_NONNULL(1);
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2025 Red Hat, Inc.