[libvirt] [PATCH 4/8] qemu: Don't repeat virDomainObjEndAPI in qemuDomainBlockPull

[Peter Krempa]

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 <pkrempa at 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.