async closures y los pecados clasicos del runtime

Cerramos el nivel con dos temas que parecen dispares y no lo son. El primero es una novedad que la edición 2024 por fin estabilizó: los closures async, async || { ... }, y su familia de traits AsyncFn, AsyncFnMut y AsyncFnOnce. Durante años se escribía un sucedáneo —un closure normal que devolvía un future— que funcionaba a medias y fallaba justo cuando querías que el future tomara prestado del entorno capturado. Los async closures cierran ese hueco. El segundo tema son los dos pecados capitales del async, los que compilan sin quejarse y luego arruinan el rendimiento o cuelgan el servicio: bloquear el hilo del runtime y sostener un lock a través de un .await. No son bugs exóticos; son la forma en que casi todo el mundo se estrella la primera vez. Terminar el nivel entendiéndolos es la diferencia entre escribir async que compila y escribir async que escala.

Closures async y los traits AsyncFn

Un closure async se escribe anteponiendo async a la lista de parámetros. Al llamarlo produce un future, que esperas con .await; y lo aceptas en una función con un bound AsyncFn, del mismo modo que aceptabas closures normales con Fn:

async fn para_cada<F: AsyncFn(u32)>(f: F) {
    for i in 0..3 {
        f(i).await; // llamar devuelve un future; se espera
    }
}

let base = leer_config().await;
para_cada(async |i| {
    let r = servicio(i).await; // el cuerpo puede tener sus propios .await
    registrar(base, i, r).await;
}).await;

La jerarquía calca la de los closures síncronos que ya conoces. AsyncFnOnce se llama una vez y consume; AsyncFnMut se llama muchas con &mut self; AsyncFn se llama muchas con &self. Como antes, el compilador deduce cuál implementa tu closure según lo que haga con sus capturas, y al pedir uno conviene exigir el trait más permisivo que tu uso tolere.

Por qué AsyncFn y no Fn que devuelve impl Future

Antes de la edición 2024 no había sintaxis async ||. El apaño era un closure corriente cuyo cuerpo era un bloque async: |x| async move { ... }, con tipo impl Fn(X) -> impl Future. Funcionaba para casos simples, pero chocaba contra un muro en cuanto el future devuelto necesitaba tomar prestado del propio closure:

// El viejo apaño: un Fn que devuelve un future.
fn hazlo<F, Fut>(f: F) where F: Fn(u32) -> Fut, Fut: Future<Output = ()> {
    // ...
}

El problema es de expresividad de tipos. En Fn(u32) -> Fut, el tipo Fut del future es fijo e independiente del préstamo de &self del closure; no hay forma de decir “el future que devuelvo vive prestado de lo que el closure capturó”. Por eso, un closure que capturaba un Vec y quería que su future lo leyera por referencia no compilaba: el future no podía atarse a la vida del &self. AsyncFn resuelve esto porque su future asociado está parametrizado por el préstamo de la llamada —conceptualmente, un tipo asociado genérico sobre la vida de &self—, de modo que el future sí puede sostener referencias al entorno capturado.

Pecado uno: bloquear el hilo del runtime

Ahora los dos errores que definen a quien todavía no ha interiorizado el modelo. El primero: meter trabajo bloqueante o de CPU largo dentro de una tarea async. Un .await cede el hilo; una llamada bloqueante, no. Mientras ese trabajo corre, el hilo trabajador del runtime queda congelado y ninguna otra tarea que dependa de él avanza, aunque su E/S ya esté lista.

async fn manejador_malo() {
    std::thread::sleep(Duration::from_secs(1)); // CONGELA el hilo del runtime
    let datos = std::fs::read("archivo").unwrap(); // E/S sincrona: bloquea igual
    let h = hash_lentisimo(&datos); // bucle de CPU: bloquea igual
}

Cada una de esas tres líneas es un pecado: thread::sleep en vez de tokio::time::sleep, lectura síncrona en vez de tokio::fs, y un cálculo largo sin ceder. El remedio depende del tipo de trabajo: para esperas, usa la versión async; para cómputo pesado inevitable, delégalo a un pool aparte con spawn_blocking, que lo saca del hilo del executor.

El síntoma de este pecado es escurridizo porque no hay error de compilación: el servicio simplemente se vuelve a ratos irresponsivo, con latencias que se disparan bajo carga sin causa aparente. La pista reveladora es que las tareas vecinas —las que comparten hilo trabajador con la que bloquea— se atascan a la vez, en ráfagas. Herramientas como tokio-console hacen visible el problema mostrando tareas que monopolizan el hilo sin ceder; sin ellas, el diagnóstico se apoya en la disciplina de sospechar de toda llamada síncrona dentro de una async fn.

async fn manejador_bien() {
    tokio::time::sleep(Duration::from_secs(1)).await; // cede el hilo
    let datos = tokio::fs::read("archivo").await.unwrap(); // E/S async
    let h = tokio::task::spawn_blocking(move || hash_lentisimo(&datos)).await.unwrap();
}

Pecado dos: sostener un lock a través de un await

El segundo pecado es más insidioso porque a veces compila y a veces no, y en ambos casos hace daño. Consiste en adquirir el guard de un Mutex y mantenerlo vivo cruzando un .await:

async fn incrementa_mal(m: &std::sync::Mutex<u64>) {
    let mut g = m.lock().unwrap(); // adquiere el lock
    *g += 1;
    guardar_en_db(*g).await;       // g SIGUE VIVO durante toda la espera
} // g se suelta aqui, demasiado tarde

Esto tiene dos consecuencias, ambas malas. Primera, de corrección concurrente: mientras la tarea está cedida en guardar_en_db().await —que puede tardar milisegundos—, nadie más puede tomar el lock; has serializado a todas las tareas a través de la espera más lenta, y si el propio código de dentro intenta reentrar, tienes un deadlock. Segunda, de tipos: el guard de std::sync::Mutex es !Send, así que un future que lo mantiene vivo a través de un .await se vuelve !Send, y tokio::spawn —que exige Send— lo rechaza en compilación con el célebre error “future cannot be sent between threads safely”. El arreglo es acotar la sección crítica: toma el lock, haz lo mínimo, suéltalo antes del .await.

async fn incrementa_bien(m: &std::sync::Mutex<u64>) {
    let valor = {
        let mut g = m.lock().unwrap();
        *g += 1;
        *g
    }; // g se suelta AQUI, antes de cualquier espera
    guardar_en_db(valor).await; // ya no hay lock vivo
}

El bloque interno no es cosmético: delimita con precisión la vida del guard, que se dropea al cerrar la llave, antes del .await. Extraes de la sección crítica solo el valor que necesitas llevarte, y la espera ocurre ya sin lock. El deadlock más traicionero aparece incluso en un runtime de un solo hilo: si mantienes el guard vivo y el guardar_en_db().await cede a otra tarea que intenta tomar el mismo lock, esa tarea se bloquea, el hilo no puede volver a la primera para que lo suelte, y el programa se congela sin un solo hilo extra de por medio. Acotar la sección crítica cierra esa puerta por construcción.

flowchart TB
L[Lock adquirido guard vivo] --> AW[await en medio de la seccion critica]
AW --> P1[La tarea cede con el lock tomado]
P1 --> P2[Otras tareas no pueden entrar serializa o deadlock]
P1 --> P3[Si el guard no es Send el future no es Send no spawnea]
AW --> FIX[Arreglo suelta el guard antes del await]
FIX --> OK[Seccion critica corta el future vuelve a ser Send]
style AW fill:#f38ba8,color:#11111b
style P2 fill:#f38ba8,color:#11111b
style P3 fill:#fab387,color:#11111b
style OK fill:#a6e3a1,color:#11111b