c - 最近的 GTK 3.22 是否仍然对 Boehm GC 友好(线程问题)？

Question

Boehm's conservative garbage collector非常有用(例如 Bigloo 正在使用它，Guile 正在使用类似的东西，等等......)，特别是在 Linux 上(这是我唯一关心的操作系统；我正在使用 Debian/Sid/x86- 64 如果这很重要，libgc-dev 包是版本 1:7.4.2-8 所以 Boehm GC 是 7.4.2)。

但是，Boehm 的 GC 需要了解每个使用它的线程。它的gc_pthreads_redirects.h (或多或少是内部的)头文件正在将pthread_create重新定义为

# define pthread_create GC_pthread_create

其实Boehm的GC需要的是GC_register_my_thread在新线程调用栈的早期调用(GC_pthread_create 正在这样做)。

过去，Glib (2.46) 提供了一种使用 struct GMemVTable which is deprecated 重新定义内存分配的方法。 并且无法再使用(我的 Debian 的 libglib2.02.0-dev 软件包版本为 2.50.3-2)。有一个g_mem_gc_friendly global boolean但是当查看 Glib 源代码时，它只是在释放内存区域之前清除它们。

最近的 GTK3(我的 libgtk-3-dev 包的版本为 3.22.11-1)正在创建线程(可能与 Dbus 相关，也可能与GtkTextView...) 使用(间接)pthread_create 通过 Glib thread functions .并且没有办法(除非通过修补源代码)被通知该线程创建。我担心我安装的任何 GTK 回调(例如使用 g_signal_connect )可能会从这些线程调用。或者，如果我使用某些可能使用(或访问)某些 GC_malloc 缓冲区的方法对 GTK 小部件进行子类化，则可能会发生灾难。

另一方面，GTK 中有一个严格的编码规则，即所有 GTK 操作都应该只在主线程中发生。引用Gdk3 Threads页:

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”.

如果我自己遵守这条规则，我确信没有内部 GTK 代码会从某个非主线程调用我的回调(使用 Boehm GC)？

我的直觉是，如果 GC_alloc 被 GTK 内部从主线程外部调用(不是直接被我的代码调用)，就会发生灾难 (因为这些 GTK 内部线程还没有用 GC_pthread_create 启动；可能会调用我的一些代码，例如，因为我正在子类化一些现有的 GTK 小部件，或者因为我连接了一些 GTK 信号，即使我不要自己在主线程之外使用 GTK 和 Boehm GC 编写代码。)。

重点是 Boehm 的 GC 需要扫描每个可能使用它的线程中的每个堆栈。

FWIW，我报告了一个可能的 bug#780815在 GTK bugzilla 上。

一个典型的例子是来自 GTK-3.22.11 tarball 的 gtk+-3.22.11/examples/application9/。 pthread_create is called g_application_run 通过 g_bus_get_sync

非常间接地执行

Answer 1

Gtk 不会从非主线程调用任何信号处理程序。您在 Gtk 应用程序中找到的任何工作线程都通过消息队列与主线程交互。您可以在 Glib 源代码中看到这一点。例如，参见 gdbusconnection.c 中 g_dbus_connection_signal_subscribe() 和 schedule_callbacks() 的实现。 .(工作线程调用 g_source_attach(..., subscriber->context)，其中第二个参数是 g_main_context_ref_thread_default() 返回的内容。)

因此您不需要使用g_mem_set_vtable() 覆盖内存分配例程。如果您以前这样做过，那将是一个非常糟糕的设计，您将 GLib/Gtk 中完美的手动内存管理实现替换为自动但不完善(且不稳定)的内存管理方案 Boehm GC。