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