최근의 GTK 3.22는 아직 Boehm GC에 우호적인가(스레드 문제)?

최근의 GTK 3.22는 아직 Boehm GC에 우호적인가(스레드 문제)?

Boehm의 보수적인 가비지 콜렉터는 특히 Linux에서 유용합니다(예를 들어 Bigloo가 사용하고 있거나 Guile이 유사한 것을 사용하고 있는 경우 등).그것이 중요한 경우 Debian/Sid/x86-64를 사용하고 있습니다.libgc-dev패키지는 버전입니다.1:7.4.2-8따라서 Boehm GC는 7.4.2)입니다.

그러나 Boehm의 GC는 이를 사용하는 모든 스레드를 인식해야 합니다.gc_pthreads_redirects.h(다소 내부) 헤더 파일은 다음과 같이 재정의됩니다.

# define pthread_create GC_pthread_create

실제로 Boehm의 GC가 필요로 하는 것은 새로운 스레드콜 스택의 초기에 호출되는 GC_register_my_thread입니다.GC_pthread_create그렇게 하고 있습니다).

Glib(2.46)는 더 이상 사용할 수 없는 메모리 할당을 재정의하는 방법을 제공했습니다(내 Debian).libglib2.02.0-dev패키지는 버전입니다.2.50.3-2글로벌 부울이 있지만 Glib 소스 코드를 조사하면 메모리존을 클리어하고 나서 해방됩니다.

최신 GTK3 (마이)libgtk-3-dev패키지에 버전이 있습니다.3.22.11-1)는 (간접적으로)를 사용하여 스레드(Dbus와 관련된 것으로 생각되며 GtkTextView와 관련된 것으로 생각됨)를 작성합니다.pthread_createGlib 스레드 기능을 사용합니다.또한 (소스 코드를 패치하는 것 이외에는) 스레드 작성에 대해 통지할 방법이 없습니다.(예를 들어 를 사용하여) 설치하는 GTK 콜백은 이러한 스레드에서 호출될 수 있습니다.또는 GTK 위젯을 사용(또는 액세스)할 수 있는 방법으로 하위 분류하는 경우GC_malloc-ed 버퍼에 문제가 있을 수 있습니다.

한편, GTK 에서는, 모든 GTK 조작은 메인 스레드만으로 행해져야 한다는 강력한 코딩 룰이 있습니다.Gdk3 스레드 페이지를 인용하려면:

그러나 GTK+는 스레드 세이프가 아닙니다.스레드에서 GTK+ 및 GDK만 사용해야 합니다.gtk_init()그리고.gtk_main()호출되었습니다.이것은 통상 「메인 스레드」라고 불립니다.

제가 이 규칙을 따를 경우, 내부 GTK 코드는 (Boehm GC를 사용하여) 비메인 스레드에서 콜백을 호출하지 않습니다.

내 직감으로는 만약 그렇다면GC_alloc메인 스레드 외부에서 GTK 내부(내 코드에 의해 직접 호출되지 않음)에 의해 재해가 발생합니다(이러한 GTK 내부 스레드가 시작되어 있지 않기 때문에).GC_pthread_create기존 GTK 위젯을 서브클래스하고 있거나 메인 스레드 이외의 GTK 및 Boehm GC를 사용하여 직접 코드를 작성하지 않아도 GTK 신호를 연결했기 때문에 코드가 호출될 수 있습니다).

핵심은 Boehm의 GC가 모든 스레드의 스택을 스캔해야 한다는 것입니다.

FWIW, GTK bugzilla에서 버그 #780815가 발생할 수 있다고 보고했습니다.

대표적인 예는 다음과 같습니다.gtk+-3.22.11/examples/application9/GTK-3.22.11 타르볼 pthread_create 에 의해 매우 간접적으로 불리고 있다.g_application_run★★★★★★★★★★★★★★★★★를 통해g_bus_get_sync

언급URL : https://stackoverflow.com/questions/43141659/is-recent-gtk-3-22-still-boehm-gc-friendly-thread-issue