Threading-Probleme mit GTK

Ich baue eine ziemlich einfache C-Anwendung Verwenden von GTK, müssen jedoch einige blockierende E / A ausführen, die Aktualisierungen der GUI auslösen. Dazu fange ich neu an pthread kurz bevor gtk_main() als solche:

/* global variables */
GMainContext *mainc;

/* local variables */
FILE *fifo;
pthread_t reader;

/* main() */
mainc = g_main_context_default();
pthread_create(&reader, NULL, watch_fifo, argv[argc-1]);
gtk_main();

Wenn der pthread liest einige Daten, aktualisiert es die GUI wie folgt:

g_main_context_invoke(mainc, set_icon, param);

Wo set_icon ist

gboolean set_icon(gpointer data)
{
    char *p = (char*)data;
    gtk_status_icon_set_from_icon_name(icon, p);
    return FALSE;
}

Meistens funktioniert das alles, aber hin und wieder bekomme ich diese merkwürdige Fehlermeldung:

[xcb] Unknown sequence number while processing queue
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
mktrayicon: xcb_io.c:274: poll_for_event: Assertion `!xcb_xlib_threads_sequence_lost' failed.

Ich dachte, der ganze Sinn der Verwendung g_main_context_invoke war es, Probleme mit Threads zu vermeiden? Beim Googeln bin ich darauf gestoßen gdk_threads_init, gdk_threads_enter und Freunde, aber sie scheinen alle veraltet zu sein? Ich weiß, dass die GTK-Dokumentation besagt, dass alle GUI-Updates im Haupt-Thread durchgeführt werden sollten, aber dies lässt sich nicht so gut mit dem Blockieren von IO kombinieren, und ich würde es vorziehen, keinen komplexen Kommunikationsmechanismus zwischen den Threads aufbauen zu müssen.

Nun meine Frage, wie gehe ich richtig damit um?

EDIT: Der vollständige Code ist zu sehen hier
EDIT2: Als Update basierend auf der Antwort von @ptomato bin ich umgezogen GThreads und verwenden gdk_threads_add_idle() wie in … gesehen Dies committen, aber das Problem ist immer noch vorhanden.

Anruf XInitThreads(). Dies sollte vorher erfolgen gtk_initdas wird die Nachrichten stoppen!

Etwas wie das:

    #include <X11/Xlib.h>
    ...  
    XInitThreads();
    ...
    gtk_init(&argc, &argv);

Ich kann mich nicht erinnern, diese Nachrichten vor GLIB 2.32 gesehen zu haben, als
g_thread_init()/gdk_threads_init() wurden verwendet.

Vielleicht möchten Sie auschecken g_thread_pool_new und g_thread_pool_push. Aus Thread verwenden g_main_context_invoke in der Hauptschleife auszuführen oder den Thread einfach dazwischen zu wickeln gdk_threads_enter()/gdk_threads_leave()

Ich verwende kein Tablett, daher kann ich dies nicht einfach überprüfen. Ich denke, Sie haben Recht mit gdk_threads_add_idle, das Sperren zum Schutz der GTK/GDK-API verwendet. Für mich ist nichts offensichtlich, was dazu führen würde, dass diese Nachrichten erscheinen. In der Funktionsbeschreibung für gtk_status_icon_new_from_icon_name heißt es: „Wenn das aktuelle Symbolthema geändert wird, wird das Symbol entsprechend aktualisiert. Was für mich bedeutet, dass Ihr Code nicht der einzige Code ist, der auf die X-Anzeige zugreift, was möglicherweise das Problem sein könnte.

Es gibt auch einige verwandte Informationen zu XInitThreads() unter

Was ist der Nachteil von XInitThreads()?

Beachten Sie, dass während GDK Sperren für die Anzeige verwendet, GTK/GDK niemals XInitThreads aufruft.

Nebenbei bemerkt: Was schützt die globale Variable “onclick”, die nach einem fork() an execl übergeben wird, das untergeordnete Element erbt nicht die Speichersperren des übergeordneten Elements, und GLib mainloop ist mit fork() nicht kompatibel. Vielleicht könnten Sie die Zeichenfolge in eine lokale Variable kopieren.

Ich bin mir nicht sicher, ob Bare-Pthreads garantiert mit GTK funktionieren. Sie sollten die GThread-Wrapper verwenden.

Ich denke, was das Problem sein könnte, ist das g_main_context_invoke() fügt hinzu set_icon() als Leerlauffunktion. (Es scheint, dass das hinter den Kulissen vor sich geht, aber ich bin mir nicht sicher.) Idle-Funktionen, die mit der API von GLib hinzugefügt werden, müssen, obwohl sie im Haupt-Thread ausgeführt werden, die GDK-Sperre halten. Wenn Sie die verwenden gdk_threads_add_idle() API (die nicht veraltet ist) zum Aufrufen set_icon()dann sollte mit dem Threading alles richtig funktionieren.

(Obwohl dies nur eine wilde Vermutung ist.)

Um dies zu umgehen, wenn Sie nur vermeiden möchten, die Benutzeroberfläche zu blockieren, während Sie auf einige IO warten, können Sie das asynchrone IO von verwenden GIO. Das würde verhindern, dass Sie Threads selbst verwalten müssen.

Bearbeiten: Wenn Sie darüber nachdenken, könnten Sie Ihre Dateideskriptoren einfach als nicht blockierend markieren und sie als Quelle zur Glib-Hauptschleife hinzufügen, und sie werden sie in der Hauptereignisschleife für Sie abfragen, ohne sich mit Threads herumschlagen zu müssen.

Sie könnten die Verwendung von Threads vermeiden, indem Sie gio_add_watch() verwenden, das Ihre Callback-Funktion aufruft, wenn Daten auf dem Kanal verfügbar sind.