qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 3/4] docs: document use of automatic cleanup fun


From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [PATCH 3/4] docs: document use of automatic cleanup functions in glib
Date: Wed, 28 Aug 2019 16:20:28 +0100
User-agent: Mutt/1.12.1 (2019-06-15)

On Wed, Aug 28, 2019 at 04:14:00PM +0100, Alex Bennée wrote:
> > +The cleanup functions are not restricted to simply free'ing memory. The
> > +GMutexLocker class is a variant of GMutex that has automatic locking and
> > +unlocking at start and end of the enclosing scope
> > +
> > +In the following example, the `lock` in `MyObj` will be held for the
> > +precise duration of the `somefunc` function
> > +
> > +    typedef struct {
> > +        GMutex lock;
> > +    } MyObj;
> > +
> > +    char *somefunc(MyObj *obj) {
> > +        g_autofree GMutexLocker *locker = g_mutex_locker_new(&obj->lock)
> > +        g_autofree char *foo = g_strdup_printf("foo%", "wibble");
> > +        g_autoptr (GList) bar = .....
> > +
> > +        if (eek) {
> > +           return NULL;
> > +        }
> > +
> > +        return g_steal_pointer(&foo);
> > +    }
> 
> I would personally prefer we get some RFC patches for auto-unlocking under our
> belt before we codify it's usage in our developer docs. Locking is a
> fickle beast at the best of times and I'd like to see where it benefits
> us before there is a rush to covert to the new style.
> 
> For one thing the only uses I see of g_mutex_lock is in our tests, the
> main code base uses qemu_mutex_lock. How would we go about registering
> the clean-up functions for those in the code base?

Ideally we could just relpace qemu_mutex with g_mutex, but if that's
not possible we would have to create a clone of GMutexLocker as
QemuMutexLocker doing exactly the same thing. It is a shame to reinvent
the wheel with our threading code though.

/me tries to remember what it was that we can do with QEMU's threads
that we can't do with GLib's threads.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]