Re: Glib mutex doesn't work on Windows

[Chris Vine <chris cvine freeserve co uk>]

On Fri, 17 Dec 2010 18:30:28 +0100 (CET)
Michael T. <myso77 seznam cz> wrote:
> > That is not of itself an error, but it invites the question
> > whether, for example, he has called g_thread_init().
>
> Yeah, you're right. I called the test function before calling
> gtk_init(), which also takes care of the g_thread_init(). So I found
> out, that GStaticMutex actually worked for my test sample program,
> but didn't work in the developed application as expected. After heavy
> investigation I realized that using mutexes is not a good solution
> for what I was trying to achieve and that the random behaviour was
> rather a design problem. I used a different way for thread
> synchronization and it works fine.

I don't think that gtk_init() does call g_thread_init().  Pre-glib-2.26
(I think, it may be pre-2.24) g_thread_init() had to be called before
any other glib call. gtk_init() initialises the type system for you -
there is no need to call g_type_init(), but this does not extend I
believe to thread support.

As it happens I don't believe it calls gdk_threads_init() either,
but gdk_threads_init() doesn't apply to windows programs (nor is it
necessary for gtk+ programs for unix-like systems where only one
thread addresses gtk+ functions).

In a multi-threaded program you need to call g_thread_init() in order
to make glib thread safe, irrespective of whether you use GThreads.  So
I should make an early and explicit call to g_thread_init().  If you
want to support earlier versions of glib, you must make the call to
g_thread_init() before any other glib or gtk+ call.

> By the way, what is OP?

Original poster.

Chris