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 :|
