After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 566578 - gtk_module_init is not always protected by GDK thread locks.
gtk_module_init is not always protected by GDK thread locks.
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: .General
2.14.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2009-01-05 01:40 UTC by rainwoodman
Modified: 2009-01-05 04:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description rainwoodman 2009-01-05 01:40:32 UTC 
Please describe the problem:
gtk_module_init is not always protected by GDK thread locks.

Case 1: the module is loaded via GtkSettings, the lock is held.
Case 2: the module is loaded at gtk_init. the lock is not held.

the general Gtk+ behavior is to automatically hold the gdk lock when calling external code. Therefore case 2 should be fixed.

Steps to reproduce:



Actual results:


Expected results:


Does this happen every time?


Other information:
Workaround: put the library init code to a g_idle callback with gdk locks; add the callback in gtk_module_init.
Comment 1 Matthias Clasen 2009-01-05 04:03:12 UTC 
Actually, I'm surprised by the second case. A threaded application is supposed to call gdk_threads_enter() before gtk_init(), so I don't see how the lock could not be held inside gtk_init(). 

See the examples in http://library.gnome.org/devel/gdk/2.14/gdk-Threads.html
Comment 2 rainwoodman 2009-01-05 04:18:55 UTC 
Ops. I didn't read that example. If Gtk.init shall be wrapped by threads_enter/leave then this should not be a bug of GTK.

My experience was that my module was getting sort of random results when plugged into a mono app. After did the g_idle trick the result become converged. 

I am not familiar with mono though. Perhaps they are forgetting the gdk lock at gtk_init or it is a problem with my module?
Comment 3 Matthias Clasen 2009-01-05 04:45:03 UTC 
Sounds like a gtk-sharp problem, in that case.