QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: "Daniel P. Berrangé" <berrange@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 3/4] docs: document use of automatic cleanup functions in glib
Date: Wed, 28 Aug 2019 17:04:23 +0100
Message-ID: <874l215la0.fsf@linaro.org> (raw)
In-Reply-To: <20190828152028.GM2991@redhat.com>


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


  reply index

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-23 16:39 [Qemu-devel] [PATCH 0/4] docs: add docs about use of automatic cleanup functions Daniel P. Berrangé
2019-08-23 16:39 ` [Qemu-devel] [PATCH 1/4] docs: convert CODING_STYLE and HACKING to markdown syntax Daniel P. Berrangé
2019-08-28 12:25   ` Alex Bennée
2019-08-28 13:08     ` Daniel P. Berrangé
2019-08-23 16:39 ` [Qemu-devel] [PATCH 2/4] docs: merge HACKING.md contents into CODING_STYLE.md Daniel P. Berrangé
2019-08-23 19:35   ` Eric Blake
2019-08-28 15:06     ` Alex Bennée
2019-08-28 15:10       ` Daniel P. Berrangé
2019-08-23 16:39 ` [Qemu-devel] [PATCH 3/4] docs: document use of automatic cleanup functions in glib Daniel P. Berrangé
2019-08-23 19:53   ` Eric Blake
2019-08-28  9:00   ` Stefan Hajnoczi
2019-08-28 15:14   ` Alex Bennée
2019-08-28 15:20     ` Daniel P. Berrangé
2019-08-28 16:04       ` Alex Bennée [this message]
2019-08-23 16:39 ` [Qemu-devel] [PATCH 4/4] docs: add table of contents to CODING_STYLE.md Daniel P. Berrangé
2019-08-23 21:48 ` [Qemu-devel] [PATCH 0/4] docs: add docs about use of automatic cleanup functions Marc-André Lureau
2019-08-28 12:30   ` Alex Bennée
2019-08-28 13:07     ` Daniel P. Berrangé

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874l215la0.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org qemu-devel@archiver.kernel.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox