Viaje de ida y vuelta (X11)
Una petición que debe esperar la respuesta del servidor antes de que el programa pueda continuar: la operación más cara del protocolo X y la razón de que un toolkit pudiera tardar segundos en arrancar por un enlace lento.
La mayoría de las peticiones X, dibujar una línea, mover una ventana, no tienen respuesta; Xlib las acumula en un búfer y las envía por lotes. Pero XInternAtom, XGetWindowAttributes, XQueryTree, XGetGeometry y XSync exigen contestación, y Xlib se bloquea hasta que llega. En local, por un socket Unix, es una fracción de milisegundo; en una red con 50 ms de latencia, cada petición de esas es una vigésima de segundo parado. Una aplicación Motif podía internar cientos de átomos y consultar la geometría de cada widget al arrancar, y de ahí las esperas tan familiares en los terminales X y por módem.
Los remedios han sido muchos. Xlib ganó XInternAtoms para traer muchos átomos en una sola respuesta. LBX y después NX pusieron un proxy junto al servidor que contestaba desde caché. XCB se construyó en 2001 exactamente para esto: cada petición devuelve una cookie de inmediato y la respuesta se recoge solo cuando hace falta, de modo que diez preguntas pueden estar en vuelo a la vez. Los toolkits aprendieron a cachear los atributos de las ventanas en lugar de pedirlos. El tratamiento de errores es un caso especial: como los errores se notifican de forma asíncrona, el programa no sabe que una llamada falló hasta el siguiente viaje de ida y vuelta, y eso es lo que hace tan difícil razonar sobre el manejador de errores de X.