Gestione degli errori in Xlib
Perché un programma X può morire per un errore in una richiesta inviata venti chiamate prima, e che cosa fanno al riguardo XSetErrorHandler e -sync.
Xlib mette in buffer le richieste e non attende le risposte se non è costretta, perciò quando il server ne rifiuta una – BadWindow per una finestra già distrutta, BadMatch per una pixmap di profondità errata, BadAccess, BadAlloc, BadValue – l'errore torna come evento molto dopo la chiamata che l'ha causato. Il gestore predefinito stampa «X Error of failed request» con il codice d'errore, l'opcode (Major opcode 20 (X_GetProperty)), l'ID della risorsa e due numeri di serie, poi termina il programma. I numeri di serie sono l'indizio: il numero della richiesta fallita confrontato con quello corrente dice di quanto si è in ritardo.
XSetErrorHandler installa un gestore proprio, cosa che fa quasi ogni window manager, perché un client può distruggere la propria finestra tra il momento in cui il gestore ne viene a conoscenza e quello in cui agisce; quella corsa non si può vincere, solo ignorare. XSetIOErrorHandler copre l'altro caso, una connessione interrotta, da cui non si torna indietro. Per il debug, XSynchronize o l'opzione Xt -sync fa attendere a ogni richiesta la propria risposta, così l'errore cade nella chiamata giusta e un breakpoint su _XError in gdb mostra dove; il prezzo è un'andata e ritorno per richiesta. XCB ha ricostruito il modello: gli errori tornano come risposta alla richiesta che li ha causati, raccolti con xcb_request_check o dalla coda degli eventi, e non c'è alcun gestore globale che si possa dimenticare di installare.