Round Trip (X11)
Eine Anfrage, bei der das Programm auf die Antwort des Servers warten muss, bevor es weitermachen kann: die teuerste Operation im X-Protokoll und der Grund, warum ein Toolkit über eine langsame Leitung Sekunden zum Starten brauchen konnte.
Die meisten X-Anfragen – eine Linie zeichnen, ein Fenster verschieben – haben keine Antwort; Xlib stellt sie in einen Puffer und schickt sie gebündelt ab. Aber XInternAtom, XGetWindowAttributes, XQueryTree, XGetGeometry und XSync verlangen eine Antwort, und Xlib blockiert, bis sie eintrifft. Lokal über einen Unix-Socket ist das ein Bruchteil einer Millisekunde; in einem Netz mit 50 ms Latenz bedeutet jede solche Anfrage eine zwanzigstel Sekunde Stillstand. Eine Motif-Anwendung konnte beim Start Hunderte von Atomen internieren und die Geometrie jedes Widgets abfragen, was die bekannten Wartezeiten an X-Terminals und über Modems erzeugte.
Die Gegenmittel waren zahlreich. Xlib bekam XInternAtoms, um viele Atome in einer Antwort zu holen. LBX und später NX stellten neben den Server einen Proxy, der aus dem Cache antwortete. XCB wurde 2001 genau dafür gebaut: Jede Anfrage liefert sofort ein Cookie zurück, und die Antwort wird erst abgeholt, wenn man sie braucht, sodass zehn Fragen gleichzeitig unterwegs sein können. Toolkits lernten, Fensterattribute zu cachen, statt jedes Mal zu fragen. Einen Sonderfall bildet die Fehlerbehandlung: Da Fehler asynchron gemeldet werden, erfährt ein Programm erst beim nächsten Round Trip, dass ein Aufruf fehlgeschlagen ist, und das macht den X-Error-Handler so schwer durchschaubar.