Is recent GTK 3.22 still Boehm GC friendly (thread

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

GTK+ is not written with a garbage collector in mind. You would have to modify GDK and the libraries it's built on, to to call the GC_* allocation functions for this to work. Simply notifying the GC of the extra GLib threads does not seem to be a solution here.

That said, this might be a non-issue if GTK+ and the libraries it uses, are backed by a different heap than the Boehm GC. Your application might not be entirely free of memory leaks and other issues, but at least all the code you write would be properly GC'd.