From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Zihan Yang <whois.zihan.yang@gmail.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] RAMList: replace QemuMutex with CompatGMutex
Date: Tue, 20 Feb 2018 13:14:15 +0100 [thread overview]
Message-ID: <ad515c08-346e-bc73-acf7-da8fdbc631bd@redhat.com> (raw)
In-Reply-To: <CAFEAcA8urY-pXDeZ5Hq33O2JOfWiVkdL2XRwWoCnXxSM6Q4B3Q@mail.gmail.com>
On 16/02/2018 10:13, Peter Maydell wrote:
> On 14 February 2018 at 12:11, Paolo Bonzini <pbonzini@redhat.com> wrote:
>> On 14/02/2018 12:43, Zihan Yang wrote:
>>>
>>>> I'm not sure what is the advantage of this change. QEMU is more or less
>>>> uniformly using QemuMutex and QemuCond.
>>>
>>> I see. QEMU uses some glib functions, like g_new, g_free, g_hash_table ,
>>> g_assert and g_poll, so I thought there was a trend for making more use
>>> of glib.
>>> I get the point now.
>>
>> There are some plans about using priority inheritance mutexes for
>> QemuMutex. GLib does not support anymore pluggable thread functions, so
>> we are stuck with our own implementation.
>
> Should we remove the entry
> "Change QemuMutex and QemuCond to CompatGMutex and CompatGCond (these are
> the same as GMutex and GCond, just with a different type). With this change,
> qemu_mutex_init/qemu_cond_init becomes optional for global variables."
> from https://wiki.qemu.org/Contribute/BiteSizedTasks then?
Yes, good idea.
Paolo
prev parent reply other threads:[~2018-02-20 12:14 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-14 8:49 [Qemu-devel] [PATCH] RAMList: replace QemuMutex with CompatGMutex Zihan Yang
2018-02-14 10:13 ` Paolo Bonzini
2018-02-14 11:43 ` Zihan Yang
2018-02-14 12:11 ` Paolo Bonzini
2018-02-16 9:13 ` Peter Maydell
2018-02-20 12:14 ` Paolo Bonzini [this message]
Reply instructions:
You may reply publicly 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=ad515c08-346e-bc73-acf7-da8fdbc631bd@redhat.com \
--to=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=whois.zihan.yang@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).