title: Is recent GTK 3.22 still Boehm GC friendly (thread issue)?
body: <p>The <a href="https://www.hboehm.info/gc/" rel="noreferrer">Boehm's conservative garbage collector</a> is quite useful (e.g. <a href="https://www-sop.inria.fr/indes/fp/Bigloo/" rel="noreferrer">Bigloo</a> is using it, <a href="http://www.gnu.org/software/guile" rel="noreferrer">Guile</a> 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 <code>libgc-dev</code> package is version <code>1:7.4.2-8</code> so the Boehm GC is 7.4.2).</p>
  <p>However, <strong>Boehm's GC</strong> requires to be aware of every thread using it. Its <a href="https://github.com/ivmai/bdwgc/blob/master/include/gc_pthread_redirects.h#L80" rel="noreferrer">gc_pthreads_redirects.h</a> (more or less internal) header file <strong>is redefining <code>pthread_create</code></strong> as</p>
  <pre><code># define pthread_create GC_pthread_create
  </code></pre>
  <p>Actually, what Boehm's GC needs is <a href="https://github.com/ivmai/bdwgc/blob/master/include/gc.h#L1393" rel="noreferrer">GC_register_my_thread</a> to be called early in the new thread call stack (and <code>GC_pthread_create</code> is doing that).</p>
  <p>In the past, Glib (2.46) provided a way to redefine memory allocation using <a href="https://developer.gnome.org/glib/2.52/glib-Memory-Allocation.html#GMemVTable" rel="noreferrer"><code>struct GMemVTable</code> which is <strong>deprecated</strong></a> <strong>and cannot be used</strong> anymore (my Debian's <code>libglib2.02.0-dev</code> package is version <code>2.50.3-2</code>). There is a <a href="https://developer.gnome.org/glib/2.52/glib-Memory-Allocation.html#g-mem-gc-friendly" rel="noreferrer"><code>g_mem_gc_friendly</code> global boolean</a> but when looking into Glib source code it simply clears memory zones before freeing them.</p>
  <p>Recent GTK3 (my <code>libgtk-3-dev</code>  package has version <code>3.22.11-1</code>) are creating threads (for something probably related to Dbus, and perhaps also to GtkTextView...) using (indirectly) <code>pthread_create</code> thru <a href="https://developer.gnome.org/glib/2.52/glib-Threads.html" rel="noreferrer">Glib thread functions</a>. 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 <a href="https://developer.gnome.org/gobject/2.52/gobject-Signals.html#g-signal-connect" rel="noreferrer"><code>g_signal_connect</code></a>) might be called from these threads. Or that if I subclass a GTK widget with some methods which might use (or access) some <code>GC_malloc</code>-ed buffer there could be a disaster.</p>
  <p>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 <a href="https://developer.gnome.org/gdk3/stable/gdk3-Threads.html" rel="noreferrer">Gdk3 Threads</a> page:</p>
  <blockquote>
  <p><strong>GTK+</strong>, however, <strong>is <em>not</em> thread safe</strong>. You should only use GTK+ and GDK from the thread <code>gtk_init()</code> and <code>gtk_main()</code> were called on. This is usually referred to as the “main thread”.</p>
  </blockquote>
  <p>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?</p>
  <p>My intuition is that if ever <code>GC_alloc</code> 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 <code>GC_pthread_create</code>; 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 &amp; Boehm GC outside of the main thread.).</p>
  <p>The point is that Boehm's GC needs to scan every stack in every thread possibly using it.</p>
  <p>FWIW, I reported a possible <a href="https://bugzilla.gnome.org/show_bug.cgi?id=780815" rel="noreferrer">bug#780815</a> on GTK bugzilla.</p>
  <p>A typical example is <code>gtk+-3.22.11/examples/application9/</code> from GTK-3.22.11 tarball. <code>pthread_create</code> <a href="https://bugzilla.gnome.org/page.cgi?id=traceparser/trace.html&amp;trace_id=237313" rel="noreferrer"><em>is called</em></a> very indirectly by <code>g_application_run</code> via <code>g_bus_get_sync</code></p>