GNOME Bugzilla – Bug 780815
Possible incompatibility of GTK 3.22 with Boehm GC (because of threads)
Last modified: 2018-05-02 18:20:28 UTC
http://stackoverflow.com/q/43141659/841108 is a better description. I'm summarizing it here. (Plartform: Debian/Sid/x86-64; GTK is 3.22.11, Glib is 2.50.3) I'm not sure of a bug. Perhaps it just requires a documentation clarification. Boehm's GC https://www.hboehm.info/gc/ is requiring that every thread using it should be created with GC_pthread_create.... But it looks that GTK is creating threads (e.g. for DBus stuff, or GtkTextView stuff) "behind my back". Can I be sure that if I correctly follow the GTK coding rule of only having GTK code called from the main thread, the internal threads never call my routines (e.g. GTK signal slots or GTK methods that I have provided by subclassing GTK classes) which are using GC_malloc ? struct GMemVTable is deprecated.... Thanks for reading. Basile Starynkevitch (France) == http://starynkevitch.net/Basile/ email basile at starynkevitch dot net
All GTK+ API will always be called in the main thread - i.e. the one that called gtk_init() and is spinning the default main context. GTK+ would not work any other way, and any use of GTK+ API outside of the main thread results in undefined behaviour. The documentation for GTK+ specifies this here: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
Even if GTK+ creates a separate thread internally, all user callbacks will be invoked in the main thread.
GTK+ does not create any threads behind your back. GLib does create threads for its own purposes. They are created with pthread_create. #define pthread_create GC_pthread_create is simply not an adequate solution
A possible workaround could be to add some hook to replace pthread_create by GC_pthread_create (or something else). Actually, what is really needed by Boehm's GC is to have GC_register_my_thread called early in the new thread. See https://github.com/ivmai/bdwgc/blob/master/include/gc.h#L1393 for more. Adding some hook to permit this could be enough.
BTW, I just compiled gtk+-3.22.11/examples/application9/ code with -g, and run it in the debugger. I did add a break point on pthread_create. It is reached: (gdb) bt
+ Trace 237313
but the thread word does not appear in any *.[ch] file. This is what I say that GTK is creating threads behind my back. That application9 code does not mention threads.
Perhaps a few sentences of additional documentation (which could go with that of g_mem_gc_friendly ...) might be enough: just tell in what cases (perhaps subclassing GtkApplication ??) user provided code (e.g. calling GC_malloc) is called outside of the main thread.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/796.