Re: [libvirt] [PATCH 4/8] qemu: Don't repeat virDomainObjEndAPI in qemuDomainBlockPull
On Fri, Sep 27, 2019 at 07:48:55 -0500, Eric Blake wrote: > On 9/27/19 1:33 AM, Peter Krempa wrote: > > On Thu, Sep 26, 2019 at 17:02:49 -0500, Eric Blake wrote: > > > On 9/26/19 10:51 AM, Peter Krempa wrote: > > > > Add a 'cleanup' label and use jumps as we do in other places. > > > > > > > > Signed-off-by: Peter Krempa > > > > --- > > > >src/qemu/qemu_driver.c | 17 ++--- > > > >1 file changed, 10 insertions(+), 7 deletions(-) > > > > > > > + cleanup: > > > > +virDomainObjEndAPI(); > > > > +return ret; > > > >} > > > > > > Is there any way to make virDomainObjEndAPI() replaceable by AUTO > > > framework? > > > > It will probably require a new macro or a new type to avoid breaking > > semantics we've established. > > > > > > > We could introduce something like VIR_AUTORELEASE and VIR_AUTOUNLOCK for > > use with virOjbectLockable-based objects. The former would then do the > > required virObjectUnlock and then virObjectUnref. The latter is for > > parity in cases when the lock should be dropped. > > > > I'll propose these and see how it will go. > > glibc has GMutexLocker which is a way to release a lock on all exit paths > after its use (or to release the lock early). > https://developer.gnome.org/glib/stable/glib-Threads.html#g-mutex-locker-new > You can use that for inspiration. I opted to do something similar to VIR_AUTOUNREF in this iteration, but we already use a very similar approach to what you've suggested in VIR_XPATH_NODE_AUTORESTORE so that might also be a way forward. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/8] qemu: Don't repeat virDomainObjEndAPI in qemuDomainBlockPull
On 9/27/19 1:33 AM, Peter Krempa wrote: On Thu, Sep 26, 2019 at 17:02:49 -0500, Eric Blake wrote: On 9/26/19 10:51 AM, Peter Krempa wrote: Add a 'cleanup' label and use jumps as we do in other places. Signed-off-by: Peter Krempa --- src/qemu/qemu_driver.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) + cleanup: +virDomainObjEndAPI(); +return ret; } Is there any way to make virDomainObjEndAPI() replaceable by AUTO framework? It will probably require a new macro or a new type to avoid breaking semantics we've established. We could introduce something like VIR_AUTORELEASE and VIR_AUTOUNLOCK for use with virOjbectLockable-based objects. The former would then do the required virObjectUnlock and then virObjectUnref. The latter is for parity in cases when the lock should be dropped. I'll propose these and see how it will go. glibc has GMutexLocker which is a way to release a lock on all exit paths after its use (or to release the lock early). https://developer.gnome.org/glib/stable/glib-Threads.html#g-mutex-locker-new You can use that for inspiration. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/8] qemu: Don't repeat virDomainObjEndAPI in qemuDomainBlockPull
On Thu, Sep 26, 2019 at 17:02:49 -0500, Eric Blake wrote: > On 9/26/19 10:51 AM, Peter Krempa wrote: > > Add a 'cleanup' label and use jumps as we do in other places. > > > > Signed-off-by: Peter Krempa > > --- > > src/qemu/qemu_driver.c | 17 ++--- > > 1 file changed, 10 insertions(+), 7 deletions(-) > > > + cleanup: > > +virDomainObjEndAPI(); > > +return ret; > > } > > Is there any way to make virDomainObjEndAPI() replaceable by AUTO framework? It will probably require a new macro or a new type to avoid breaking semantics we've established. VIR_AUTOPTR is unuitable because the semantics say that the object will be freed. VIR_AUTOCLEAN is similarly unsuitable because we don't clean anything inside, but AUTOCLEAN can be used internally in some cases as e.g. with the autmatic XPath context cleanup code. VIR_AUTOUNREF is not enough in this case because we are dealing with a lockable object. We could introduce something like VIR_AUTORELEASE and VIR_AUTOUNLOCK for use with virOjbectLockable-based objects. The former would then do the required virObjectUnlock and then virObjectUnref. The latter is for parity in cases when the lock should be dropped. I'll propose these and see how it will go. -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [PATCH 4/8] qemu: Don't repeat virDomainObjEndAPI in qemuDomainBlockPull
On 9/26/19 10:51 AM, Peter Krempa wrote: Add a 'cleanup' label and use jumps as we do in other places. Signed-off-by: Peter Krempa --- src/qemu/qemu_driver.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-) + cleanup: +virDomainObjEndAPI(); +return ret; } Is there any way to make virDomainObjEndAPI() replaceable by AUTO framework? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
