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

Question

该贝姆保守的垃圾收集器的(如相当有用中的bigloo时,用它狡诈使用类似的东西,等...),尤其是在Linux操作系统(这是我关心的只是OS;我使用Debian/SID/86 -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该方法已 被弃用且不能再使用(我的Debian libglib2.02.0-dev软件包是版本2.50.3-2).有一个g_mem_gc_friendly全局布尔值,但在查看Glib源代码时,它只是在释放它们之前清除内存区域.

最近的GTK3(我的libgtk-3-dev 软件包有版本3.22.11-1)正在使用(间接)pthread_create通过Glib线程函数创建线程(可能与Dbus相关,也可能与GtkTextView相关...).除了通过修补源代码之外,没有办法通知该线程创建.我害怕比我g_signal_connect可以从这些线程调用的任何GTK回调(例如使用).或者,如果我使用某些可能使用(或访问)某些GC_malloc-ed缓冲区的方法对GTK小部件进行子类化,则可能会发生灾难.

另一方面,GTK中有一个强大的编码规则,所有GTK操作都应该只在主线程中发生.引用Gdk3线程页面:

GTK +,但是,是不是线程安全的.您应该只使用GTK +和GDK从线程gtk_init()和gtk_main()被称为上.这通常被称为"主线程".

如果我自己遵循这个规则,我确信没有内部GTK代码可以从一些非主线程调用我的回调(使用Boehm GC)？

我的直觉是,如果GC_alloc从GTK内部(不是直接通过我的代码)从主线程外部调用,就会发生灾难(因为这些GTK内部线程尚未启动GC_pthread_create;可能会调用我的一些代码,例如因为我正在继承一些现有的GTK小部件,或者因为我连接了一些GTK信号,即使我自己不使用主线程之外的GTK和Boehm GC编写代码.).

关键是Boehm的GC需要扫描每个可能使用它的线程中的每个堆栈.

FWIW,我在GTK bugzilla上报告了一个可能的错误#780815.

一个典型的例子gtk+-3.22.11/examples/application9/来自GTK-3.22.11 tarball.通过via 非常间接地pthread_create 调用g_application_rung_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()覆盖内存分配例程。如果您以前这样做过，那是一个非常糟糕的设计，您用自动但不完美（且不稳定）的内存管理方案 Boehm GC 取代了 GLib/Gtk 中完美的手动内存管理实现。