The Boehm's conservative garbage collector is quite useful (e.g. Bigloo is using it, Guile is using something similar, etc....), notably on Linux (which is the only OS I care about; I'm using Debian/Sid/x86-64 if that matters, and libgc-dev package is version 1:7.4.2-8 so the Boehm GC is 7.4.2).
However, Boehm's GC requires to be aware of every thread using it. Its gc_pthreads_redirects.h (more or less internal) header file is redefining pthread_create as
# define pthread_create GC_pthread_create
Actually, what Boehm's GC needs is GC_register_my_thread to be called early in the new thread call stack (and GC_pthread_create is doing that).
In the past, Glib (2.46) provided a way to redefine memory allocation using struct GMemVTable which is deprecated and cannot be used anymore (my Debian's libglib2.02.0-dev package is version 2.50.3-2). There is a g_mem_gc_friendly global boolean but when looking into Glib source code it simply clears memory zones before freeing them.
Recent GTK3 (my libgtk-3-dev package has version 3.22.11-1) are creating threads (for something probably related to Dbus, and perhaps also to GtkTextView...) using (indirectly) pthread_create thru Glib thread functions. And there is no way (except by patching the source code) to be notified of that thread creation. I'm afraid than any GTK callback I would install (e.g. using g_signal_connect) might be called from these threads. Or that if I subclass a GTK widget with some methods which might use (or access) some GC_malloc-ed buffer there could be a disaster.
On the other hand there is a strong coding rule in GTK that all GTK operations should happen only in the main thread. To quote Gdk3 Threads page:
GTK+, however, is not thread safe. You should only use GTK+ and GDK from the thread gtk_init() and gtk_main() were called on. This is usually referred to as the “main thread”.
If I follow this rule myself, I am sure that no internal GTK code will ever call my callbacks (using Boehm GC) from some non-main thread?
My intuition is that if ever GC_alloc is called from outside the main thread by GTK internals (not directly by my code) a disaster would happen
(because these GTK-internal threads have not been started with GC_pthread_create; there might call some of my code, e.g. because I am subclassing some existing GTK widget, or because I connected some GTK signal, even if I don't myself code things using GTK & Boehm GC outside of the main thread.).
The point is that Boehm's GC needs to scan every stack in every thread possibly using it.
FWIW, I reported a possible bug#780815 on GTK bugzilla.
A typical example is gtk+-3.22.11/examples/application9/ from GTK-3.22.11 tarball. pthread_create is called very indirectly by g_application_run via g_bus_get_sync
See Question&Answers more detail:
os 
