El modelo mental: una async fn es una máquina de estados

Ya sabes que .await cede el control cuando algo no está listo. Pero, ¿cómo reanuda la función justo donde la dejó, si el hilo se marchó a hacer otra cosa? La respuesta es la idea más bella del modelo async de Rust: el compilador toma tu async fn —código lineal, de arriba abajo— y lo transforma en un tipo anónimo que implementa Future, una máquina de estados con un estado por cada .await. Cada punto de suspensión es un estado; entre ellos, el código corre de un tirón. El runtime la hace avanzar llamando a poll, y cada llamada ejecuta desde el último punto de suspensión hasta el siguiente. Esto es una introducción; el nivel 33 abre la máquina en canal, con poll, Waker y Pin al detalle.

De función a máquina de estados

Toma una async fn con dos puntos de espera:

async fn saludar(id: u64) -> String {
    let nombre = leer_nombre(id).await;   // punto de suspension 1
    let saludo = componer(&nombre).await; // punto de suspension 2
    saludo
}

El compilador no genera una función que “se duerme”: genera un tipo que recuerda en qué punto va. Conceptualmente, algo como un enum con un estado por cada tramo entre .await:

// Aproximacion conceptual de lo que fabrica el compilador:
enum SaludarSM {
    Inicio { id: u64 },
    EsperandoNombre { fut: LeerNombreFut },
    EsperandoSaludo { fut: ComponerFut, nombre: String },
    Terminado,
}

La clave está en qué guarda cada estado: exactamente las variables locales que deben sobrevivir a ese punto de suspensión. Si nombre se usa después del primer .await, viaja dentro del estado que cruza esa espera. Entre dos .await, el código se ejecuta seguido. Y todo el conjunto es una sola estructura de tamaño conocido en tiempo de compilación: no hay una asignación por cada espera.

poll: el motor del avance

El runtime conduce la máquina llamando a poll, que devuelve uno de dos veredictos:

• Poll::Ready(v): terminé, aquí está el valor.
• Poll::Pending: aún no; ya me las he arreglado para que me despierten, no me consultes en bucle.

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<String> {
    // Segun el estado actual, intenta avanzar:
    //  - hace poll del sub-future que esta esperando
    //  - si ese devuelve Pending, este future devuelve Pending
    //  - si devuelve Ready, guarda el valor y pasa al siguiente estado
    //  - cuando no quedan estados, devuelve Ready(saludo)
}

El ciclo es este: el runtime hace poll; si obtiene Pending, aparca la tarea y dedica el hilo a otras; cuando algo hace posible el avance, vuelve a hacer poll; la máquina salta al estado correcto y sigue desde ahí. Lo esencial es que poll es una llamada a función normal —despacho estático, sin asignación, baratísima—. Componer futures es anidar máquinas de estados: el future de saludar contiene al de leer_nombre, y el todo colapsa en una sola máquina plana.

Dibujado en pseudocódigo, el poll de nuestra máquina es un bucle con un match sobre el estado, donde cada Pending sale cediendo y cada Ready avanza de estado:

// Version conceptual (no compila tal cual): revela el salto entre estados.
fn poll(&mut self, cx: &mut Context<'_>) -> Poll<String> {
    loop {
        match &mut self.estado {
            Estado::Inicio { id } => {
                self.estado = Estado::EsperandoNombre(leer_nombre(*id));
            }
            Estado::EsperandoNombre(fut) => match fut.poll(cx) {
                Poll::Pending => return Poll::Pending,        // cede el control
                Poll::Ready(nombre) => {                      // avanza al siguiente
                    self.estado = Estado::EsperandoSaludo(componer(nombre));
                }
            },
            Estado::EsperandoSaludo(fut) => match fut.poll(cx) {
                Poll::Pending => return Poll::Pending,
                Poll::Ready(saludo) => return Poll::Ready(saludo),
            },
        }
    }
}

Ahí está toda la magia desmitificada: no hay hilos que dormir ni pilas que salvar, solo un match que recuerda por dónde iba y un return Poll::Pending que es, literalmente, ceder.

El waker: avísame cuando pueda avanzar

Falta una pieza para que el ciclo no sea un desperdicio. Cuando un future hoja —una lectura de socket, digamos— devuelve Pending, no se limita a decir “aún no”: guarda el Waker que viaja dentro del Context y se lo entrega al reactor, diciendo “despierta esta tarea cuando este descriptor sea legible”. El reactor —epoll, kqueue— vigila miles de descriptores a la vez; en cuanto uno está listo, invoca wake(), que le pide al executor que vuelva a poner esa tarea en la cola para otro poll.

// El waker es el puente entre "no estoy listo" y "vuelve a intentarlo":
//   future hoja  --Pending-->  registra el waker en el reactor
//   reactor ve el fd listo  -->  waker.wake()  -->  el executor re-encola la tarea

Sin Waker, el executor tendría que sondear en bucle —busy-poll— preguntando “¿ya? ¿ya?” y quemando CPU. Con Waker, el executor duerme hasta que hay algo real que hacer. Por eso Poll::Pending no significa “vuelve enseguida”, sino “no vuelvas hasta que te avise”.

flowchart TD
S0[Estado inicial guarda los locales] --> P1[El runtime llama a poll]
P1 --> A1{El await actual esta listo}
A1 -->|no| PEND[Devuelve Pending y registra el waker]
PEND -->|el waker despierta la tarea| P1
A1 -->|si| S1[Guarda el valor y avanza al siguiente estado]
S1 --> A2{Quedan mas awaits}
A2 -->|si| P1
A2 -->|no| DONE[Devuelve Ready con el valor final]
style S0 fill:#89b4fa,color:#11111b
style PEND fill:#fab387,color:#11111b
style DONE fill:#a6e3a1,color:#11111b

Stackless: por qué importa

El async de Rust es sin pila (stackless). Lo que debe sobrevivir a un .await no es una pila de llamadas real sostenida por un hilo del sistema, sino los campos de esa estructura-máquina, dimensionada en compilación y almacenada allí donde viva el future —a menudo una única asignación en el heap cuando se hace spawn—. Compáralo con las corrutinas con pila o los hilos verdes de Go, que mantienen una pila real y crecible por tarea.

Las consecuencias son grandes. La composición es de coste cero: hacer .await de otro future solo incrusta su máquina como un campo; todo el árbol de llamadas async es una estructura y, al hacer spawn, una asignación. El tamaño es conocido en compilación —puede ser grande, el famoso problema de los “futures gordos”, pero es predecible—. Y hay una consecuencia que el nivel 33 desarrollará: como la máquina puede guardar una referencia a sí misma —un local prestado a través de un .await—, no debe moverse una vez que empezó a avanzar. Por eso poll recibe Pin<&mut Self>: para prometerle al future que su dirección no cambiará.