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

["Alex Bennée" <alex.bennee@linaro.org>]

Daniel P. Berrangé <berrange@redhat.com> writes:

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

Apart from having separate POSIX and Win32 implementations we have also
extended the mutex handling to add trace points and also support
profiling of lock latency.

>
> Regards,
> Daniel


--
Alex Bennée