The [Boehm&#39;s conservative garbage collector][1] is quite useful (e.g. [Bigloo][2] is using it, [Guile][3] is using something similar, etc....), notably on Linux (which is the only OS I care about; I&#39;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&#39;s GC** requires to be aware of every thread using it. Its [gc_pthreads_redirects.h][4] (more or less internal) header file **is redefining `pthread_create`** as 

    # define pthread_create GC_pthread_create


Actually, what Boehm&#39;s GC needs is [GC_register_my_thread][5] 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**][6] **and cannot be used** anymore (my Debian&#39;s `libglib2.02.0-dev` package is version `2.50.3-2`). There is a [`g_mem_gc_friendly` global boolean][7] 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][8]. And there is no way (except by patching the source code) to be notified of that thread creation. I&#39;m afraid than any GTK callback I would install (e.g. using [`g_signal_connect`][9]) 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][10] page:

&gt; **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&#39;t myself code things using GTK &amp; Boehm GC outside of the main thread.).

The point is that Boehm&#39;s GC needs to scan every stack in every thread possibly using it.

FWIW, I reported a possible [bug#780815][11] on GTK bugzilla.

A typical example is `gtk+-3.22.11/examples/application9/` from GTK-3.22.11 tarball. `pthread_create` [*is called*][12] very indirectly by `g_application_run` via `g_bus_get_sync`


  [1]: https://www.hboehm.info/gc/
  [2]: https://www-sop.inria.fr/indes/fp/Bigloo/
  [3]: http://www.gnu.org/software/guile
  [4]: https://github.com/ivmai/bdwgc/blob/master/include/gc_pthread_redirects.h#L80
  [5]: https://github.com/ivmai/bdwgc/blob/master/include/gc.h#L1393
  [6]: https://developer.gnome.org/glib/2.52/glib-Memory-Allocation.html#GMemVTable
  [7]: https://developer.gnome.org/glib/2.52/glib-Memory-Allocation.html#g-mem-gc-friendly
  [8]: https://developer.gnome.org/glib/2.52/glib-Threads.html
  [9]: https://developer.gnome.org/gobject/2.52/gobject-Signals.html#g-signal-connect
  [10]: https://developer.gnome.org/gdk3/stable/gdk3-Threads.html
  [11]: https://bugzilla.gnome.org/show_bug.cgi?id=780815
  [12]: https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&amp;trace_id=237313

All Boehm Gc Solutions on Gang of Coders

Total of 1 Boehm Gc Solutions

Is recent GTK 3.22 still Boehm GC friendly (thread issue)?