select!: reaccionar al primero que termine

join! respondía a la pregunta “¿cómo espero a que terminen todos?”. select! responde a la contraria y, a menudo, más urgente: “¿cómo reacciono al primero que termine e ignoro el resto?”. Sondea varias ramas a la vez y, en cuanto una está lista, ejecuta su bloque asociado y abandona las demás. Esa forma —una carrera con un único ganador— es la base de tres patrones omnipresentes: ponerle un límite de tiempo a una operación, cancelar trabajo cuando llega una señal de apagado, y multiplexar varias fuentes de eventos en un solo bucle. Pero el abandono de las ramas perdedoras no es gratis ni inocente: esos futures se dropean a mitad de camino, y ahí vive el error más sutil de todo el async de Rust, el que se conoce como cancellation safety.

La forma de select!: gana el primero

tokio::select! recibe una lista de ramas. Cada rama tiene un patrón, un future, una flecha y un bloque. La macro sondea todos los futures; en cuanto uno produce su valor, liga ese valor al patrón, ejecuta el bloque de esa rama y descarta los futures de las demás:

tokio::select! {
    valor = fuente_a() => {
        // fuente_a gano; fuente_b fue dropeada sin terminar
        procesar(valor);
    }
    valor = fuente_b() => {
        // fuente_b gano; fuente_a fue dropeada sin terminar
        procesar(valor);
    }
}

La diferencia con join! es total: join! conduce todos hasta el final y devuelve la tupla de todos los resultados; select! conduce todos pero se queda con uno y tira el resto. Donde join! es conjunción —“y esto, y aquello”—, select! es una disyunción con desempate temporal —“lo que ocurra antes”—.

Los tres usos: timeout, cancelación, multiplexar

El primer patrón es el timeout: corre tu trabajo contra un temporizador y quédate con quien llegue antes.

use tokio::time::{sleep, Duration};

tokio::select! {
    res = trabajo() => manejar(res),
    _ = sleep(Duration::from_secs(5)) => {
        // el temporizador gano: trabajo() se dropeo, se cancelo
        eprintln!("agotado el tiempo");
    }
}

Es tan común que Tokio lo empaqueta en tokio::time::timeout(dur, fut), que devuelve Err si vence el plazo; por dentro es este mismo select!. El segundo patrón es la cancelación cooperativa: corre el trabajo contra una señal de apagado.

loop {
    tokio::select! {
        msg = canal.recv() => match msg {
            Some(m) => procesar(m),
            None => break, // el canal se cerro
        },
        _ = &mut apagado => break, // llego la senal: sal del bucle
    }
}

El tercero es la multiplexación: un solo bucle que atiende varias fuentes —dos canales, un socket y un temporizador, eventos de teclado y de red— reaccionando a la que primero hable. select! es, en el fondo, el match del tiempo: elige rama según qué ocurre antes.

El gotcha: cancellation safety

Aquí está el filo. Cuando una rama gana, las demás se dropean en el punto exacto donde estaban esperando. Si una de esas ramas había hecho un trabajo parcial que vivía dentro del future —había leído medio mensaje de un socket a un buffer interno, había sacado un elemento de una cola sin confirmarlo—, ese progreso se pierde al dropearse. Un future es cancel-safe si dropearlo a media espera no pierde datos ni corrompe estado; es no cancel-safe si sí.

// PELIGRO si read_exact NO es cancel-safe: en cada vuelta del bucle,
// si el timer gana, los bytes ya leidos por read_exact se PIERDEN,
// porque vivian en el estado del future que acabamos de dropear.
loop {
    tokio::select! {
        r = socket.read_exact(&mut buf) => usar(&buf, r),
        _ = tick.tick() => registrar_latido(),
    }
}

La regla práctica: en un select! dentro de un bucle, cada rama debe usar operaciones cancel-safe, porque se dropearán y recrearán una y otra vez. La documentación de Tokio marca método a método su seguridad ante cancelación: mpsc::Receiver::recv es cancel-safe —si se cancela, ningún mensaje se pierde—; en cambio operaciones que acumulan estado parcial dentro del future, como read_exact o un decodificador que buffea, no lo son. Cuando necesites una operación no cancel-safe dentro de un select!, la salida es sacarla del future y darle un sitio estable donde su progreso sobreviva entre vueltas —por ejemplo, un buffer o un future pineado fuera del bucle— en lugar de recrearla cada iteración.

biased, guardas y reutilizar un future

Por defecto, select! sondea sus ramas en orden aleatorio en cada evaluación. Es deliberado: evita que una rama siempre lista hambree a las demás. Cuando de verdad necesitas un orden fijo —dar prioridad a la señal de apagado, por ejemplo— pon biased; como primera línea y las ramas se sondearán en el orden escrito:

tokio::select! {
    biased; // sondea de arriba abajo; la primera lista gana
    _ = &mut apagado => cerrar(),      // maxima prioridad
    msg = canal.recv() => atender(msg),
}

Cada rama admite además una guarda if condicion, que la desactiva cuando la condición es falsa —útil para no leer de una fuente ya agotada—, y una rama else que corre si todas las ramas están desactivadas. Hay un detalle mecánico frecuente: para reutilizar el mismo future a lo largo de varias vueltas del bucle (y no recrearlo, justo por la cancel-safety), debes pineárlo y pasarlo por referencia mutable con tokio::pin!:

let dormir = sleep(Duration::from_secs(30));
tokio::pin!(dormir); // ahora es Unpin-por-referencia y reutilizable
loop {
    tokio::select! {
        msg = canal.recv() => { reiniciar_o_procesar(msg); }
        _ = &mut dormir => { cerrar_por_inactividad(); break; }
    }
}

flowchart TB
S[select! con varias ramas] --> P[Sondea todas las ramas]
P --> W{Alguna lista}
W -->|no| P
W -->|si| G[Ejecuta el handler de la ganadora]
G --> D[Las demas ramas se DROPEAN se cancelan]
D --> R{Eran cancel-safe}
R -->|si| OK[No se pierde nada]
R -->|no| BAD[Se pierde el progreso parcial]
style G fill:#a6e3a1,color:#11111b
style D fill:#fab387,color:#11111b
style BAD fill:#f38ba8,color:#11111b