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 <pkre...@redhat.com> > > > > --- > > > > src/qemu/qemu_driver.c | 17 ++++++++++------- > > > > 1 file changed, 10 insertions(+), 7 deletions(-) > > > > > > > + cleanup: > > > > + virDomainObjEndAPI(&vm); > > > > + 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
