El Waker: cómo un future dormido pide que lo despierten

La lección anterior dejó una deuda: Poll::Pending obliga a “avisar cuando haya progreso”, pero ¿avisar cómo, y a quién? La respuesta es el Waker, quizá la pieza más ingeniosa del modelo. Un future que cede no se limita a devolver Pending: antes clona el Waker que viaja en el Context, lo guarda, y se lo entrega a quien sí sabe cuándo llegarán los datos —el sistema operativo, un temporizador, otro hilo—. Cuando ese progreso ocurre, alguien invoca wake() sobre el waker, y el executor vuelve a poner la tarea en la cola para otro poll. Sin este mecanismo, un runtime tendría que sondear en bucle preguntando “¿ya? ¿ya?” y quemar un núcleo entero girando. El Waker es lo que transforma esa rueda de hámster en un sueño tranquilo del que solo se despierta cuando hay trabajo real.

El problema: Pending sin aviso es una rueda de hámster

Imagina un runtime ingenuo, sin wakers. Tiene una lista de tareas y las recorre sondeándolas: si una da Ready, la retira; si da Pending, pasa a la siguiente y, al terminar la vuelta, empieza otra vez desde el principio. Ese bucle funciona, pero es ruinoso: gira sin descanso preguntando a cada future “¿ya estás listo?” millones de veces por segundo, aunque no haya llegado ni un byte. Un núcleo al 100 % para, en el fondo, esperar. Eso es busy-polling, y es exactamente lo que la asincronía prometía evitar.

// El runtime INGENUO sin wakers: gira sin descanso quemando un nucleo.
loop {
    for tarea in &mut tareas {
        let _ = tarea.poll(cx); // pregunta "ya?" haya o no datos que leer
    }
    // nunca duerme: aunque TODAS devuelvan Pending, vuelve a empezar la vuelta
}

El arreglo no puede ser “que el future avise”, porque un future es pasivo: solo existe cuando alguien lo sondea, y entre poll y poll no corre. La fuente del progreso no es el future, es el mundo exterior: el socket que recibe datos, el temporizador que vence, el hilo que termina un cálculo. Hace falta un canal por el que ese mundo exterior pueda decirle al runtime “la tarea que esperaba esto ya puede avanzar”. Ese canal es el Waker.

El Waker vive en el Context, se clona y se guarda

Cada llamada a poll recibe un &mut Context<'_>, y del contexto se saca el waker:

use std::task::{Context, Poll, Waker};

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<()> {
    if self.listo() {
        Poll::Ready(())
    } else {
        // Clona el waker de ESTA tarea y guardalo donde el mundo exterior lo alcance.
        let waker: Waker = cx.waker().clone();
        self.guardar_waker(waker);
        Poll::Pending
    }
}

Dos gestos importan. Primero, se clona: cx.waker() presta el waker solo durante la llamada, pero el future necesita conservarlo más allá del poll —hasta que el dato llegue, quizá milisegundos después—, así que se queda con una copia propia. Clonar un Waker es barato por diseño; internamente es poco más que un puntero contado y una tabla de funciones. Segundo, se guarda en un sitio que el productor del dato pueda alcanzar: típicamente un Arc<Mutex<Option<Waker>>> compartido con el hilo o el reactor que completará la operación.

El waker identifica una tarea concreta: llamar a wake() sobre él le dice al executor “reencola esta tarea”, no otra. Por eso cada tarea tiene el suyo, tejido por el executor cuando la hace spawn.

Ese “sitio donde guardarlo” suele ser una estructura compartida entre el future y quien completará la operación:

struct EstadoCompartido {
    listo: bool,
    waker: Option<Waker>, // el reactor o el hilo productor lo tomara y disparara
}
// se comparte como Arc<Mutex<EstadoCompartido>> entre el future y la fuente del dato

El contrato: Pending obliga a que wake se llame

Aquí se cierra la deuda de la lección anterior con una regla inflexible:

Si poll devuelve Pending, debe haber dispuesto que, tarde o temprano, se invoque wake() sobre el waker de la tarea. De lo contrario, la tarea no se volverá a sondear nunca.

No es una recomendación de rendimiento: es lo que separa una tarea que progresa de una colgada para siempre. El runtime, tras recibir Pending, aparca la tarea y se olvida de ella activamente —esa es la ganancia, deja de girar—; lo único que la resucita es un wake(). Si nadie lo llama, la tarea duerme hasta el fin del programa, sin panic ni error, solo silencio. Por eso disparar el waker es responsabilidad ineludible de quien devuelve Pending.

El Waker ofrece dos formas de disparar, según lo que tengas a mano:

waker.wake();          // consume el waker: uso tipico tras take() del Option
waker.wake_by_ref();   // dispara sin consumirlo: util si lo necesitas de nuevo

Llamar a wake() no ejecuta el future en el acto ni lo sondea: solo lo marca como listo para sondear y lo devuelve a la cola del executor, que lo atenderá cuando le toque. Despertar es encolar, no correr.

Reactor y executor: quién despierta a quién

El modelo reparte el trabajo en dos mitades que conviene no confundir:

• El executor es el motor que ejecuta: mantiene la cola de tareas listas y las sondea con poll. Es quien fabrica los wakers y quien, al recibir un wake(), reencola la tarea.
• El reactor es el vigía que observa el mundo: se apoya en epoll, kqueue o io_uring para vigilar miles de descriptores a la vez, y cuando uno se vuelve legible, dispara el waker que el future hoja dejó registrado.

El waker es el puente entre ambos. Un future hoja que lee de un socket, al recibir Pending del sistema, guarda su waker en el reactor asociado a ese descriptor. El reactor duerme sobre epoll vigilando todos los descriptores de golpe. Cuando el socket recibe datos, epoll despierta al reactor, que localiza el waker de esa tarea y llama a wake(); eso la reencola en el executor, que la vuelve a poll; esta vez la lectura tiene datos y el future avanza. Ningún hilo estuvo esperando a ese socket en particular: uno solo vigilaba todos.

// El reparto de papeles, en pseudocodigo:
//   [reactor]   epoll_wait(descriptores)  ->  fd listo  ->  waker.wake()
//   [waker]     wake()  ->  encola la tarea en la cola de listas del executor
//   [executor]  saca la tarea de la cola  ->  fut.poll(cx)  ->  Ready o Pending

flowchart LR
L[Future hoja devuelve Pending] --> G[Guarda el waker clonado en el reactor]
G --> R[El reactor vigila el descriptor con epoll]
R -->|el socket recibe datos| K[El reactor llama a wake sobre el waker]
K --> E[El executor reencola la tarea]
E --> P[Nuevo poll ahora la lectura avanza]
style L fill:#fab387,color:#11111b
style R fill:#89b4fa,color:#11111b
style K fill:#cba6f7,color:#11111b
style P fill:#a6e3a1,color:#11111b