Problemi di filettatura con GTK

Question

Sto creando un semplice C application utilizzando GTK, ma devo eseguire alcuni IO di blocco che attiveranno gli aggiornamenti alla GUI. Per fare questo, comincio una nuova pthread destra prima gtk_main() in quanto tale:

/* 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(); 

Quando il pthread legge alcuni dati, si aggiorna l'interfaccia grafica in questo modo:

g_main_context_invoke(mainc, set_icon, param); 

Dove set_icon è

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

Questo tutto funziona la maggior parte del tempo, ma ogni tanto ottengo questo curioso messaggio di errore:

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

Ho pensato che il punto principale dell'utilizzo di g_main_context_invoke era evitare problemi con i thread? Facendo un po 'di googling, mi sono imbattuto in gdk_threads_init, gdk_threads_enter e amici, ma sembrano tutti deprecati? So che la documentazione di GTK dice che tutti gli aggiornamenti della GUI dovrebbero essere eseguiti sul thread principale, ma questo non combina molto bene con l'IO di blocco, e preferirei non dover costruire un meccanismo di comunicazione complesso tra i thread.

E quindi, la mia domanda è, come devo affrontare correttamente questo?

EDIT: Il codice completo è visibile here EDIT2: come un aggiornamento in base alla risposta di @ ptomato, mi sono trasferito a GThread s ed utilizzando gdk_threads_add_idle() come si vede nella this impegnarsi, ma il problema è ancora presente.

Answer 1

chiamata XInitThreads(). Questo dovrebbe essere fatto prima del gtk_init, che fermerà i messaggi!

Qualcosa di simile a questo:

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

Non mi ricordo di aver visto questi messaggi prima GLIB 2.32, quando g_thread_init()/gdk_threads_init() sono stati utilizzati.

Si potrebbe voler verificare g_thread_pool_new e g_thread_pool_push. Da filo, utilizzare g_main_context_invoke da eseguire nel ciclo principale o semplicemente avvolgere filo tra gdk_threads_enter()/gdk_threads_leave()

non uso un vassoio quindi non posso controllata agevolmente.Penso che tu sia corretto su gdk_threads_add_idle utilizzando i blocchi per proteggere le API GTK/GDK. Non c'è nulla di ovvio per me che faccia apparire questi messaggi a . La descrizione della funzione per gtk_status_icon_new_from_icon_name afferma che "Se il tema dell'icona corrente viene modificato, l'icona sarà aggiornata a . Che per me, implica che il codice non è l'unico codice che accederà alla visualizzazione X, che potrebbe essere il problema.

ci sono anche alcune informazioni correlate per quanto riguarda XInitThreads() in

What is the downside of XInitThreads()?

Nota che mentre GDK utilizza i blocchi per il display, GTK/GDK Non bisogna mai XInitThreads chiamata.

Su un lato nota: Cosa sta proteggendo la variabile globale "onclick", che viene passato a execl dopo una fork(), Il bambino non erediterà blocca la memoria del padre, e GLib mainloop è incompatibile con fork() . Forse potresti copiare la stringa sulla variabile locale.

Answer 2

Non sono sicuro che i pthread nudi siano garantiti per funzionare con GTK. Dovresti usare i wrapper GThread.

Penso che il problema potrebbe essere che g_main_context_invoke() aggiunge set_icon() come una funzione inattiva. (Sembra che sia quello che succede dietro le quinte, ma non ne sono sicuro.) Le funzioni di inattività aggiunte usando l'API di GLib, nonostante siano eseguite sul thread principale, devono contenere il blocco GDK. Se si utilizza l'API gdk_threads_add_idle() (che non è deprecata) per richiamare set_icon(), allora tutto dovrebbe funzionare correttamente con il threading.

(Anche se questa è solo una supposizione.)

Answer 3

Come soluzione, se si desidera evitare di bloccare l'interfaccia utente mentre si attende un qualche IO, è possibile utilizzare l'I/O asincrono da GIO. Ciò eviterebbe di dover gestire autonomamente i thread.

Modifica: Pensandoci potresti semplicemente contrassegnare i descrittori di file come non bloccanti e aggiungerli come sorgente al ciclo principale di glib e li interrogherà nel ciclo degli eventi principale senza dover fare confusione con i thread .

Answer 4

È possibile evitare l'uso dei thread utilizzando gio_add_watch() che invocherà la funzione di richiamata quando sono disponibili dati sul canale.