Deadlocks y stalls async: cuando el await no vuelve

El nivel 31 trazó una frontera incómoda: Rust demuestra la ausencia de carreras de datos, pero no la de interbloqueos, porque el progreso es una propiedad de viveza y refutarla equivale al problema de la parada. Async no mueve esa frontera; le añade territorio. A las formas clásicas —dos hilos con candados en orden opuesto— se suman patologías nuevas que solo existen porque el flujo de control es ahora un dato que se suspende: un candado async retenido a través de un .await, dos tareas que se esperan mutuamente por un canal lleno, un waker que se pierde y deja un Future dormido para siempre, o —el pecado más propio de async— una llamada bloqueante que congela al executor y hambrea a todas las tareas vecinas. Todos comparten la firma que el nivel 31 describió: son programas seguros —sin unsafe, sin corrupción— que simplemente nunca vuelven de un .await. Y como no hay pánico, RUST_BACKTRACE calla; la detección exige las herramientas de este nivel. Aprender a reconocer cada patrón es aprender a leer el silencio.

El candado retenido a través del await

El nivel 31 te advirtió: nunca sostengas un guard mientras llamas a código que no controlas. En async esa regla se vuelve más aguda, porque un .await es ceder el control a código que no controlas —el resto de tus tareas—. Sostener un tokio::sync::Mutex a través de un .await es la receta canónica del interbloqueo async:

use tokio::sync::Mutex;
use std::sync::Arc;

async fn transferir(estado: Arc<Mutex<Cuenta>>) {
    let mut guard = estado.lock().await;
    guard.saldo -= 10;
    confirmar_en_red(&guard).await; // MAL: el guard sigue vivo cruzando el await
    guard.saldo += 0;
}

Mientras la tarea está suspendida en confirmar_en_red, retiene el candado. Si otra tarea —o esta misma en otra invocación— necesita lock() para avanzar, y de su avance depende que confirmar_en_red termine, se cierra el ciclo: cada una espera a la otra, ninguna suelta. La cura es la misma disciplina del nivel 31 llevada a async: encoge la sección crítica para que no cruce ningún .await. Copia lo que necesites, suelta el guard con drop, y solo entonces suspende.

async fn transferir(estado: Arc<Mutex<Cuenta>>) {
    let snapshot = {
        let mut guard = estado.lock().await;
        guard.saldo -= 10;
        guard.clone()          // copio lo necesario
    };                         // el guard muere aqui, ANTES del await
    confirmar_en_red(&snapshot).await;
}

Esperas circulares y awaits que no resuelven

La segunda familia son tareas que se esperan entre sí sin ningún candado a la vista. El vehículo típico es un canal acotado lleno: la tarea A no puede enviar a B porque el buffer de B está lleno, y B no puede vaciarlo porque está bloqueada enviando a A, cuyo buffer también está lleno. Es la espera circular del nivel 31, pero tejida con send().await en vez de lock().

// A espera hueco en el canal hacia B; B espera hueco en el canal hacia A.
tx_a_b.send(msg).await.unwrap(); // se bloquea si el buffer de B esta lleno
// ... y simetricamente en la otra tarea. Ciclo cerrado, nadie drena.

Un pariente más solitario es el .await que nunca resuelve, sin que haya ciclo alguno. Ocurre cuando el Future que esperas jamás recibirá la señal que lo completa:

• El emisor se cayó: esperas un oneshot::Receiver cuyo Sender se soltó sin enviar. Aquí Tokio es amable y el await resuelve con Err(RecvError) en vez de colgarse —siempre que no ignores ese Result—.
• La notificación nunca llega: esperas un Notify::notified() y ninguna tarea llama a notify_one(), o esperas datos en un canal cuyo productor terminó sin cerrar bien.
• El waker se perdió: en un Future escrito a mano, guardaste mal el Waker —o no lo guardaste— y devolviste Poll::Pending. Nadie volverá a sondear la tarea: se durmió y no hay quien la despierte. Es el interbloqueo de una sola tarea consigo misma, y tokio-console lo marca literalmente como “lost waker”.

Bloquear el executor: el stall más traicionero

El stall más propio de async no es un ciclo: es un solo egoísta. Si una tarea llama a una operación bloqueante —std::thread::sleep, E/S síncrona, un Mutex de std que se queda esperando, o un bucle de CPU largo— no cede el hilo trabajador en un .await, sino que lo congela. En un runtime current_thread, con un solo hilo, eso detiene el mundo entero: ninguna otra tarea avanza. En un runtime multihilo, hambrea a un trabajador; y si suficientes tareas bloquean suficientes trabajadores a la vez, el runtime se para en seco aunque no haya ningún ciclo lógico.

async fn manejar() {
    std::thread::sleep(Duration::from_secs(2)); // congela el hilo trabajador
    // Debia ser: tokio::time::sleep(Duration::from_secs(2)).await;
}

flowchart TD
P[La tarea no vuelve del await] --> Q1[Retiene un candado cruzando el await]
P --> Q2[Espera circular por canal lleno]
P --> Q3[Waker perdido o emisor caido]
P --> Q4[Llamada bloqueante congela el executor]
Q1 --> D[tokio-console tarea idle para siempre]
Q2 --> D
Q3 --> D
Q4 --> E[tokio-console poll time enorme]
style P fill:#f38ba8,color:#11111b
style Q4 fill:#fab387,color:#11111b
style D fill:#89b4fa,color:#11111b
style E fill:#89b4fa,color:#11111b

La diferencia diagnóstica importa: un interbloqueo o un waker perdido dejan a la tarea idle —dormida, con poll time bajo, sin progresar—, mientras que bloquear el executor deja un poll que no termina —poll time altísimo—. tokio-console distingue los dos casos de un vistazo, exactamente por las métricas de la lección anterior. Y la primera herramienta defensiva, antes de abrir la consola, es envolver toda espera sospechosa en un límite temporal, que convierte un cuelgue silencioso en un error visible:

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

match timeout(Duration::from_secs(5), operacion()).await {
    Ok(v) => v,
    Err(_) => tracing::error!("operacion colgada: posible deadlock o waker perdido"),
}