On Fri, 17 Dec 2010 18:30:28 +0100 (CET) Michael T. <mys...@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 _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
