qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] osdep: initialize glib threads in all QEMU tool


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] osdep: initialize glib threads in all QEMU tools
Date: Tue, 8 Oct 2013 14:25:50 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 08.10.2013 um 11:58 hat Stefan Hajnoczi geschrieben:
> glib versions prior to 2.31.0 require an explicit g_thread_init() call
> to enable multi-threading.
> 
> Failure to initialize threading causes glib to take single-threaded code
> paths without synchronization.  For example, the g_slice allocator will
> crash due to race conditions.
> 
> Fix this for all QEMU tool programs (qemu-nbd, qemu-io, qemu-img) by
> moving the g_thread_init() call from vl.c:main() into a new
> osdep.c:thread_init() constructor function.
> 
> thread_init() has __attribute__((constructor)) and is automatically
> invoked by the runtime during startup.
> 
> We can now drop the "simple" trace backend's g_thread_init() call since
> thread_init() already called it.
> 
> Note that we must keep coroutine-gthread.c's g_thread_init() call which
> is located in a constructor function.  There is no guarantee for
> constructor function ordering so thread_init() may only be called later.

The glib documentation says:

    Since version 2.24, calling g_thread_init() multiple times is
    allowed, but nothing happens except for the first call.

I take that this means previously it wasn't allowed. qemu's configure
checks for a minimum version of 2.12, so we seems to support glib
versions that don't allow g_thread_init() to be called multiple times.

Do we need to protect against this?

Kevin



reply via email to

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