thread::spawn y JoinHandle: lanzar un hilo y cosechar su valor

Hasta ahora cada programa ha sido una sola línea de ejecución: una pila, un flujo de control que desciende por main instrucción tras instrucción. Un hilo rompe esa unicidad. thread::spawn toma una clausura y le concede una pila propia y un flujo de control propio que el sistema operativo planifica a la vez que el resto del programa. Lo que recibes a cambio no es el resultado —el hilo puede no haber terminado todavía— sino un JoinHandle<T>, un recibo tipado. Con él, y solo con él, te reúnes con el hilo mediante join: bloqueas hasta que acabe y cosechas lo que devolvió. Todo el nivel gira sobre esa pareja —lanzar y reunir— y sobre las garantías que el compilador exige para que lanzar no signifique corromper.

Un hilo es una clausura con pila propia

Lanzar un hilo es entregar una clausura a thread::spawn. La llamada retorna al instante, sin esperar a que el trabajo termine:

use std::thread;

fn main() {
    let hijo = thread::spawn(|| {
        for i in 1..=3 {
            println!("hilo hijo: {i}");
        }
    });

    for i in 1..=3 {
        println!("hilo principal: {i}");
    }

    hijo.join().unwrap();   // sin esto, main podria acabar antes que el hijo
}

Desde la llamada a spawn hay dos hilos vivos, cada uno con su propia pila y planificado de forma independiente por el núcleo. El orden en que se intercalan sus println! no está determinado: puede cambiar entre ejecuciones. Rust adopta un modelo de hilos 1:1: cada thread::spawn crea un hilo nativo del sistema operativo —un pthread en Unix, un hilo del núcleo en Windows—, no un hilo verde de un planificador propio. Rust tuvo hilos verdes M:N antes de la 1.0 y los retiró: un lenguaje de sistemas no debe imponer un runtime pesado, y el modelo 1:1 deja el coste y el control del planificador en manos del sistema operativo.

La firma condensa el nivel entero:

pub fn spawn<F, T>(f: F) -> JoinHandle<T>
where
    F: FnOnce() -> T + Send + 'static,
    T: Send + 'static,

La clausura es FnOnce porque el hilo la invoca una sola vez. Ha de ser Send + 'static —transportable a otro hilo y sin referencias prestadas de duración limitada—, exigencias que desmenuzan las lecciones dos y tres. Y T, lo que la clausura devuelve, viaja de vuelta al hilo que haga join; por eso también es Send.

join: bloquear y cosechar el valor

El JoinHandle<T> no es decoración: es el único canal por el que recuperas el valor de retorno del hilo. join toma self por valor —consume el manejador, así que solo puedes reunirte con un hilo una vez— y bloquea al llamante hasta que el hijo termina:

use std::thread;

fn main() {
    let handle = thread::spawn(|| {
        let mut suma = 0u64;
        for i in 1..=1_000 { suma += i; }
        suma                         // este valor viajara al que haga join
    });

    let total: u64 = handle.join().unwrap();
    println!("el hilo calculo {total}");
}

join devuelve thread::Result<T>, que es Result<T, Box<dyn Any + Send + 'static>>. El caso Ok lleva el valor que la clausura devolvió. El caso Err aparece cuando el hilo entró en pánico, y su Box<dyn Any> transporta la carga del panic! —el &str o String del mensaje—, recuperable con downcast_ref:

let handle = thread::spawn(|| panic!("algo se rompio dentro"));

match handle.join() {
    Ok(()) => println!("termino sin incidentes"),
    Err(carga) => {
        if let Some(msg) = carga.downcast_ref::<&str>() {
            println!("el hilo entro en panico: {msg}");
        }
    }
}

Un pánico en un hilo secundario no derriba el proceso: desenrolla solo la pila de ese hilo y se convierte en el Err de su join. Ese aislamiento —un fallo local que no se vuelve global— es una de las razones por las que los hilos son fronteras naturales de contención, como viste con catch_unwind. En cambio, un pánico en el hilo principal termina el proceso.

Builder: nombre, pila y creación falible

thread::spawn es azúcar de Builder::new().spawn(...).unwrap(). Si el sistema operativo no puede crear el hilo —agotó memoria o el límite de hilos—, ese unwrap interno entra en pánico. thread::Builder expone la operación falible y dos atributos que spawn fija por defecto:

use std::thread;

let builder = thread::Builder::new()
    .name("trabajador-io".to_string())   // aparece en panicos y depuradores
    .stack_size(4 * 1024 * 1024);        // 4 MiB en vez del defecto (~2 MiB)

let handle = builder
    .spawn(|| {
        let actual = thread::current();
        println!("soy {}", actual.name().unwrap_or("anonimo"));
    })
    .expect("el SO no pudo crear el hilo");   // spawn devuelve io::Result

handle.join().unwrap();

El spawn de Builder devuelve io::Result<JoinHandle<T>>, para que decidas tú qué hacer ante el fallo en lugar de entrar en pánico. El nombre viaja a los mensajes de diagnóstico; el tamaño de pila importa cuando un hilo hace recursión profunda o reserva buffers grandes en la pila, y el defecto de unos 2 MiB se queda corto. thread::current() devuelve un manejador al hilo en curso, con el que consultar su nombre o su identificador (ThreadId).

flowchart TD
S[thread spawn recibe una clausura FnOnce] --> J[Devuelve un JoinHandle de tipo T]
S --> R[El hilo hijo corre a la vez con su propia pila]
J -->|join toma self y bloquea| W[Espera a que el hijo termine]
W --> OK[Ok con el valor que devolvio la clausura]
W --> ER[Err con la carga del panic del hilo]
style S fill:#89b4fa,color:#11111b
style J fill:#cba6f7,color:#11111b
style OK fill:#a6e3a1,color:#11111b
style ER fill:#f38ba8,color:#11111b