select: esperar por lo primero que ocurra

Hasta aquí toda espera ha sido una espera por algo determinado: este canal, este resultado, este trabajo. Hay una clase de problemas que no se deja escribir así, la de esperar por lo primero que ocurra entre varias posibilidades sin comprometerse de antemano con ninguna. Consumir de dos fuentes y atender la que hable antes; enviar a la cola que tenga hueco; darle a una operación un plazo sin envolverla; competir dos peticiones y quedarse con la que gane. select es la construcción que resuelve esa familia entera, y su valor no está en la sintaxis sino en la garantía que la sostiene: de todas las alternativas declaradas, exactamente una se consuma y todas las demás quedan como si nunca se hubieran intentado.

La forma de la espera múltiple

select es una función suspendida que recibe un bloque donde se declaran cláusulas. Cada cláusula asocia una operación potencialmente suspendida con el código que debe ejecutarse si esa es la que gana. La función se suspende hasta que alguna esté lista, ejecuta su bloque y devuelve su valor.

suspend fun atenderPrimero(a: ReceiveChannel<String>, b: ReceiveChannel<String>): String =
    select {
        a.onReceive { "de a: $it" }
        b.onReceive { "de b: $it" }
    }

Las cláusulas disponibles cubren casi todo lo que suspende en la librería. Del lado de los canales están onReceive, que falla si el canal está cerrado, y onReceiveCatching, que en ese caso entrega un ChannelResult en lugar de lanzar; del lado del envío está onSend, que espera a que haya hueco. Un Deferred ofrece onAwait, un Job ofrece onJoin y un Mutex ofrece onLock. Que la misma construcción sirva para esperar un dato, un hueco, un resultado y un cerrojo es lo que la convierte en un mecanismo general de espera y no en una utilidad de canales.

El bloque de cada cláusula, conviene subrayarlo, se ejecuta después de que la operación se haya completado, con su resultado como receptor implícito, y puede a su vez suspender. Todas las cláusulas de un mismo select deben devolver el mismo tipo, que es el tipo de la expresión entera, y por eso a veces hay que anotarlo explícitamente cuando la inferencia no encuentra un supertipo útil.

// Enviar a la primera cola que acepte, sin bloquear en ninguna.
select<Unit> {
    rapida.onSend(evento) { }
    lenta.onSend(evento) { }
}

El caso completo, el que aparece en cualquier fusión real de dos fuentes, necesita además tratar el cierre, y para eso onReceive no basta: hay que usar la variante que devuelve un resultado y decidir qué significa que una de las ramas se haya agotado.

suspend fun fundirOrdenado(a: ReceiveChannel<Dato>, b: ReceiveChannel<Dato>) {
    var vivos = 2
    while (vivos > 0) select<Unit> {
        a.onReceiveCatching { r -> r.getOrNull()?.let(::emitir) ?: vivos-- }
        b.onReceiveCatching { r -> r.getOrNull()?.let(::emitir) ?: vivos-- }
    }
}

Ese bucle tiene un defecto instructivo: cuando una fuente se cierra, su cláusula sigue registrándose en cada vuelta y ganando de inmediato, porque un canal cerrado siempre está listo. Con el sesgo hacia la primera declarada, eso convierte el bucle en una rueda que gira sin consumir nada de la otra fuente. La corrección consiste en dejar de declarar la cláusula de una fuente agotada, y descubrir ese detalle a fuerza de leer el código es el rito de paso habitual de quien empieza con esta construcción.

Ese ejemplo con onSend merece atención porque es donde se ve la garantía. Si ambas colas tuvieran hueco, el evento se envía a una sola: la cláusula perdedora no envía nada, no ocupa espacio y no deja rastro. Sin esa atomicidad, la construcción sería inútil, porque duplicar el evento en las dos colas es precisamente lo que nadie quiere.

Sesgo, inanición y plazos

select evalúa las cláusulas en el orden en que se declararon. Si en el momento de la llamada hay varias listas, gana siempre la primera declarada. Eso no es un detalle de implementación, es comportamiento documentado, y tiene una consecuencia desagradable: si la primera fuente está saturada, las siguientes no se atienden nunca.

// Inanición: si urgentes siempre tiene algo, normales no se lee jamás.
while (true) select<Unit> {
    urgentes.onReceive { atender(it) }
    normales.onReceive { atender(it) }
}

Ese código es correcto si el sesgo es lo que quieres, es decir, si estás implementando prioridades estrictas y aceptas que la cola de baja prioridad pueda no vaciarse nunca. Si lo que querías era equidad, existe selectUnbiased, que aleatoriza el orden de registro de las cláusulas y reparte a largo plazo. La elección entre ambas es una decisión de política de planificación, y escribir select sin haberla tomado es tomarla por omisión.

flowchart TD
A[select suspende] --> B[Registra todas las clausulas]
B --> C[Alguna esta lista ya]
C -->|Si| D[Gana la primera declarada]
C -->|No| E[Espera a la primera que se active]
D --> F[Se desregistran las demas]
E --> F
F --> G[Se ejecuta solo el bloque ganador]

Conviene además saber que el sesgo solo decide entre cláusulas que ya estaban listas en el momento del registro. Si ninguna lo está, select se suspende y gana sencillamente la primera que se active, con lo cual el orden del código deja de importar y el no determinismo del entorno toma el mando. Esto explica una observación que desconcierta a mucha gente al medir: bajo carga baja el reparto parece justo aunque uses la versión sesgada, y solo cuando la contención sube aparece la inanición. El sesgo no es un comportamiento constante, es un desempate.

Los plazos entran en escena como una cláusula más. onTimeout compite con las otras alternativas y gana si nadie lo hace antes, lo cual es distinto de envolver la llamada en withTimeout. El envoltorio cancela la operación en curso y lanza una excepción; la cláusula simplemente ofrece un camino alternativo que no cancela nada y no lanza nada.

suspend fun leerConPlazo(c: ReceiveChannel<Dato>): Dato? = select {
    c.onReceive { it }
    onTimeout(500) { null }        // camino alternativo, no cancelación
}

La distinción importa cuando la operación que espera tiene efectos. Con el envoltorio, vencido el plazo, la operación se cancela y todo lo que hubiera empezado se deshace por las rutas de limpieza habituales. Con la cláusula no se cancela nada: el canal sigue ahí, el elemento que estaba a punto de llegar llegará, y quien lo reciba será la siguiente llamada. Para leer de una fuente compartida eso suele ser lo deseable; para una petición de red que ya no interesa a nadie, es una fuga con otro nombre.

La otra aplicación clásica de la construcción no involucra canales en absoluto: competir dos cálculos y quedarse con el que termine antes. Es el patrón de la petición cubierta, donde se lanza la misma consulta a dos réplicas para recortar la cola de latencia.

suspend fun elMasRapido(a: Deferred<Respuesta>, b: Deferred<Respuesta>): Respuesta =
    select {
        a.onAwait { it }
        b.onAwait { it }
    }   // el perdedor sigue vivo: cancélalo o lo estarás pagando

El comentario de la última línea señala el error más frecuente con onAwait. La cláusula perdedora no cancela nada: el otro trabajo continúa consumiendo recursos hasta terminar, y su excepción, si falla, seguirá propagándose por el ámbito. Envolver la competición en un coroutineScope propio y cancelar a los hermanos al salir es la única forma de que ganar signifique también que el resto se detiene.

La experimentalidad no es una formalidad

Casi todo lo que rodea a select exige un OptIn, y esa marca lleva ahí desde el principio. Conviene saber por qué. El motor de selección tuvo que ser reescrito por completo cuando se rehizo la implementación de los canales, porque el algoritmo antiguo, basado en un descriptor atómico de operación múltiple, era correcto pero costoso y limitaba la escalabilidad de las primitivas que participaban en él. La versión actual reduce ese coste drásticamente a cambio de un protocolo de registro más sutil, y ese protocolo es el que cualquier tipo que quiera ofrecer una cláusula propia tiene que implementar. Ahí está la razón de la marca: la interfaz que permite escribir cláusulas nuevas todavía no se considera estable.

Hay un segundo motivo, más mundano, para que la marca siga puesta: la superficie de cláusulas ha cambiado varias veces. La variante que devolvía nulo al cerrarse un canal fue sustituida por la que devuelve un resultado encapsulado, la cláusula de plazo ha ido y venido en su forma exacta, y las primitivas de sincronización han ido incorporando cláusulas propias con el tiempo. Nada de eso rompe código escrito hoy, pero explica por qué la librería prefiere no comprometerse todavía.

Para el código de aplicación, la lectura práctica es tranquilizadora y precisa a la vez. Usar select con cláusulas de la propia librería es seguro y se hace en producción todos los días. Construir cláusulas propias implementando la interfaz interna es apostar contra la siguiente versión menor. Y hay un límite que sí conviene recordar siempre: no existe una cláusula para colectar un Flow, porque un flujo frío no es una fuente esperable sino una descripción de cómo producir; si necesitas seleccionar sobre flujos, el paso obligatorio es materializarlos antes en canales.