Tema 3 · Bucle de eventos, colas y dispatching

La sesión responde a tres preguntas: de dónde sale la secuencia de eventos, cómo se despachan y qué pasa si un handler tarda.

La cocina del restaurante

Varios camareros dejan comandas en el pasador y un solo cocinero las prepara de una en una. Llega la comanda de la mesa 3 y después la de la mesa 7: el cocinero coge la primera, cocina la mesa 3 entera (la 7 espera) y luego coge la siguiente.

Quien produce y quien atiende no se esperan: el pasador absorbe la diferencia de ritmo entre ellos.

Los productores generan eventos, la cola los guarda, el bucle los saca y el dispatcher los entrega a su handler.

Algunas consecuencias que conviene tener claras:

• Una ISR (rutina de interrupción) de un pulsador es un productor típico: debe ser cortísima, así que solo encola el evento y sale. La reacción la hará después el handler, fuera de la interrupción.
• El evento lleva datos, no trabajo: «pulsador 4», «sensor 24 C». Lo que hay que hacer con él lo sabe el handler.
• Como un único hilo recorre el bucle, los handlers nunca se ejecutan a la vez entre sí.

Un sensor de puerta genera un evento cada 10 ms y el handler tarda 25 ms. No hay cola: si el handler está ocupado cuando llega un evento, no hay sitio donde esperar.

const llegadas = [0, 10, 20, 30, 40]; // ms: un evento cada 10 ms
const duracion = 25;                  // ms que tarda el handler
let libreEn = 0;

for (const t of llegadas) {
  if (t < libreEn) console.log(`t=${t}: PERDIDO (handler ocupado)`);
  else { console.log(`t=${t}: atendido`); libreEn = t + duracion; }
}

libreEn es el instante en que el handler vuelve a estar libre. Solo se atiende el evento que llega con el handler libre; al atenderlo, el handler queda ocupado otros 25 ms.

Haz la traza tú: para cada t, compara con libreEn y actualízalo si se atiende.

La salida del sensor sin cola fue:

t=0: atendido
t=10: PERDIDO (handler ocupado)
t=20: PERDIDO (handler ocupado)
t=30: atendido
t=40: PERDIDO (handler ocupado)

Ahora ponemos una cola entre medias:

const llegadas = [0, 10, 20, 30, 40];
const duracion = 25;
const cola = [...llegadas];
let reloj = 0;

while (cola.length) {
  const t = cola.shift();
  reloj = Math.max(reloj, t);
  console.log(`evento t=${t}: atendido en ${reloj} (espera ${reloj - t} ms)`);
  reloj += duracion;
}

evento t=0: atendido en 0 (espera 0 ms)
evento t=10: atendido en 25 (espera 15 ms)
evento t=20: atendido en 50 (espera 30 ms)
evento t=30: atendido en 75 (espera 45 ms)
evento t=40: atendido en 100 (espera 60 ms)

1. Los eventos esperan su turno en vez de perderse.
2. Se sacan por orden de llegada, uno cada vez (shift saca el primero).
3. El precio es la espera: crece 15 ms por evento, porque el handler tarda 25 ms y el productor genera uno cada 10 ms.

Juega con el periodo del productor y la duración del handler y observa perdidos (sin cola) y esperas (con cola):

Una cola que se vacía a tiempo es una cola sana; una cola que solo crece es un sistema mal dimensionado.

Productores que encolan, un bucle que saca por orden y un dispatcher que elige el handler por tipo. Todo cabe en unas líneas de C++:

#include <cstdio>
#include <queue>

enum Tipo { PULSADOR, TICK, SENSOR, N_TIPOS };
struct Evento { Tipo tipo; int dato; };
using Handler = void (*)(const Evento&);
std::queue<Evento> cola;

void alPulsar(const Evento& e) { std::printf("pulsador %d\n", e.dato); }
void alMedir(const Evento& e)  { std::printf("sensor %d C\n", e.dato); }
void alTick(const Evento& e) {
    std::printf("tick %d\n", e.dato);
    if (e.dato < 2) cola.push({TICK, e.dato + 1});
}

Handler tabla[N_TIPOS] = { alPulsar, alTick, alMedir };

int main() {
    cola.push({TICK, 1}); cola.push({SENSOR, 24}); cola.push({PULSADOR, 4});
    while (!cola.empty()) { Evento e = cola.front(); cola.pop(); tabla[e.tipo](e); }
}

Cómo leerlo:

• El evento es tipo + dato. Tipo es un enum, así que PULSADOR vale 0, TICK 1 y SENSOR 2. N_TIPOS (3) sirve para dimensionar la tabla.
• La tabla de handlers guarda un puntero a función por tipo, en el mismo orden que el enum.
• El bucle saca el primero (front + pop) y lo despacha.
• alTick encola un nuevo tick mientras el dato sea menor que 2.

Antes de mirar la salida en el paso siguiente, haz la traza de la cola en papel.

La salida es:

tick 1
sensor 24 C
pulsador 4
tick 2

Tres cosas que observar:

1. Un handler puede encolar eventos nuevos, que se colocan al final de la cola. El tick 2 creado por el primer handler sale el último: espera a los que ya estaban.
2. El dispatcher es una línea: tabla[e.tipo](e). El bucle no conoce la lógica de ningún evento; solo indexa la tabla.
3. El evento es tipo + dato, y el tipo indexa la tabla.

Compáralo con la barra del bar de la Hora 1: while (comandas.isNotEmpty()) + removeFirst + preparar es exactamente este while (!cola.empty()) + front/pop + tabla[...]. La diferencia es que aquí, en lugar de un when dentro del handler, hay una tabla de despacho que elige el handler por tipo.

El orden de llegada es justo, pero no distingue una alarma de un registro. Supón cuatro eventos de log de 20 ms cada uno en la cola y que llega una alarma:

El envejecimiento (aging) consiste en ir subiendo la prioridad de un evento cuanto más tiempo lleva esperando, de modo que tarde o temprano adelante a los urgentes. Es lo que le faltaba a la L21 del panel de la caldera.

Si llegan muchos eventos de estado seguidos, basta con el último. Ejemplo con un mapa que se repinta:

¿Por qué no fundir mover x=2 con mover x=4 saltándose el «tocar»? Porque cambiaría el orden de los hechos: el marcador se tocó cuando el mapa estaba en x=2, no en x=4.

Con memoria limitada, el descarte es inevitable. La decisión es qué se tira y que no pase desapercibido.

Ejemplo: una cola de 3 posiciones recibe 5 lecturas seguidas sin que el bucle saque ninguna. Con la política «descartar el más antiguo», las lecturas 1 y 2 son pisadas; en la cola quedan 3, 4 y 5, y el contador de perdidas vale 2.

Por qué cada una encaja con su ejemplo:

• En una temperatura o un GPS, la lectura vieja ya no vale: mejor quedarse con la nueva.
• En un protocolo de comandos, saltarse una orden intermedia podría dejar al otro extremo en un estado inconsistente: mejor rechazar lo nuevo (y que el emisor lo sepa).
• Al enviar un fichero por la red no se puede perder ni un byte: se frena a quien lee el fichero hasta que haya sitio.

Un handler se ejecuta entero antes de que empiece el siguiente: nada lo interrumpe, ni siquiera un evento urgente.

Ya lo has visto dos veces:

• En la barra del bar, el café del desayuno esperó al zumo.
• En el C++, el tick 2 lo creó el primer handler, pero no empezó hasta que acabaron los que ya estaban en la cola.

Una tienda web: una carga de 100 ms en el bucle y, mientras, los clics del usuario van llegando. Cada evento tiene su instante de llegada t y lo que cuesta su handler.

const eventos = [
  { t: 0,  nombre: "cargarCatalogo", coste: 100 },
  { t: 16, nombre: "clic Comprar",   coste: 2 },
  { t: 32, nombre: "scroll",         coste: 2 },
  { t: 48, nombre: "clic Carrito",   coste: 2 },
];
let reloj = 0;

for (const e of eventos) {
  reloj = Math.max(reloj, e.t);
  console.log(`${e.nombre.padEnd(15)} espera ${reloj - e.t} ms`);
  reloj += e.coste;
}

El razonamiento es el mismo que con el sensor: reloj es cuándo queda libre el bucle; cada evento empieza en max(reloj, t) y espera la diferencia con su llegada.

Haz la traza:

La salida del ejemplo anterior fue:

cargarCatalogo  espera 0 ms
clic Comprar    espera 84 ms
scroll          espera 70 ms
clic Carrito    espera 56 ms

Los clics cuestan 2 ms, pero esperan 84, 70 y 56 ms porque un handler de 100 ms bloquea el bucle. La solución sin tocar el bucle: trocear la carga en 10 trozos de 10 ms. Cada trozo, al terminar, se vuelve a encolar y los clics se cuelan entre ellos.

const cola = [
  { t: 0,  nombre: "cargar",       coste: 10, trozos: 10 },
  { t: 16, nombre: "clic Comprar", coste: 2 },
  { t: 32, nombre: "scroll",       coste: 2 },
  { t: 48, nombre: "clic Carrito", coste: 2 },
];
let reloj = 0;

while (cola.length) {
  const e = cola.shift(); reloj = Math.max(reloj, e.t);
  if (!e.trozos) console.log(`${e.nombre.padEnd(13)} espera ${reloj - e.t} ms`);
  reloj += e.coste;
  if (e.trozos > 1) {
    const sig = { ...e, t: reloj, trozos: e.trozos - 1 };
    const i = cola.findIndex((x) => x.t > sig.t);
    cola.splice(i < 0 ? cola.length : i, 0, sig);
  }
}
console.log(`carga terminada en ${reloj} ms`);

1. Cada trozo termina y devuelve el control: entre dos trozos el bucle atiende otros eventos.
2. El siguiente trozo se encola detrás de lo que ya esperaba (se inserta por instante t).
3. El coste es mínimo.

clic Comprar  espera 4 ms
scroll        espera 0 ms
clic Carrito  espera 6 ms
carga terminada en 106 ms

La misma causa produce síntomas distintos según el sistema:

Y tiene tres salidas:

El handler no es el sitio del trabajo lento. Lo que debe hacer es: leer la entrada, actualizar el estado y encolar lo siguiente.

El hilo principal (UI thread) de una app Android tiene un Looper que saca mensajes de su MessageQueue y se los da a un Handler.

A 60 Hz hay 16,7 ms entre dos señales vsync para atender los eventos y dibujar. Si un handler tarda más, se pierden fotogramas.

El presupuesto es simplemente 1000 ms / frecuencia: 1000 / 60 ≈ 16,7.

Un onClick de 42 ms

Con vsync cada ~16,7 ms (0, 16, 33, 50, 66 ms…), un onClick lento de 42 ms ocupa el hilo principal durante más de dos fotogramas enteros. Mientras corre, el hilo no puede dibujar, así que se pierden 2 fotogramas y la animación da un tirón.

Una app de reparto: al tocar «Actualizar catálogo», la app se queda congelada durante la descarga.

boton.setOnClickListener {
    val datos = descargarCatalogo()   // 3 s de red
    lista.submit(datos)
}

1. El onClick corre en el hilo principal. Durante 3 s no se atiende ningún otro evento.
2. La lista no se actualiza hasta que acaba. Ni scroll, ni animaciones, ni más toques.

Aplica lo que llevas visto:

• El onClick es un handler del Looper principal. Mientras está dentro de descargarCatalogo(), el Looper no puede sacar ningún mensaje más de la MessageQueue.
• Los toques, el scroll y los vsync siguen llegando… y se acumulan en la cola.
• Con 60 Hz, en 3 s caben unos 180 fotogramas: ninguno se dibuja.

Piensa antes de contestar: ¿qué ve el usuario en esos 3 s? ¿Y si la red tarda 8 s? ¿Dónde debería ejecutarse la descarga y cómo vuelve el resultado a la lista?

La descarga va a otro hilo, y el resultado vuelve al hilo principal publicando en su Handler.

val principal = Handler(Looper.getMainLooper())

boton.setOnClickListener {
    thread {
        val datos = descargarCatalogo()          // 3 s, sin molestar
        principal.post { lista.submit(datos) }
    }
}

1. Handler ligado al Looper principal. Handler(Looper.getMainLooper()) es la «puerta de entrada» a la cola del hilo de la UI.
2. El trabajo lento sale del bucle. El onClick solo arranca el hilo: termina en microsegundos.
3. El resultado se encola. principal.post { … } mete un Runnable en la MessageQueue del hilo principal; cuando le toque, el Looper lo ejecuta y la lista se actualiza desde el hilo principal, el único que puede tocar la UI.

Es la salida «delegar» de la tabla de handlers largos. Y fíjate en que el resultado vuelve como un evento más: el patrón productor → cola → bucle → handler aparece de nuevo, con el hilo de descarga como productor.

Seis preguntas para diseñar o depurar un sistema por eventos:

Puente a la Unidad 4

Ya sabemos que los eventos llegan de uno en uno y en orden. Pero un mismo evento («pulsar») debe hacer cosas distintas según el momento: el mismo botón enciende si está apagado y apaga si está encendido; el mismo «SUBIR» del panel puede subir la temperatura o cambiar de menú.

Eso no se resuelve con más colas ni más prioridades: se modela con máquinas de estado, el tema de la U4.