Scoped threads: prestar de la pila del padre sin miedo

El bound 'static de thread::spawn era pesimista por necesidad: como spawn no puede prometer cuándo terminará el hilo, exige el máximo, que nada prestado de la pila del padre cruce la frontera. Pero muchísima concurrencia real es más disciplinada: lanzas unos hilos, esperas a que todos acaben, y solo entonces continúas. Si el patrón garantiza que ningún hilo sobrevive al ámbito que lo lanzó, entonces prestar de la pila del padre es perfectamente seguro, porque la pila sigue viva mientras los hilos corren. thread::scope —estable desde Rust 1.63— captura exactamente ese patrón: abre un ámbito, deja que sus hilos tomen prestados los datos locales, y no retorna hasta que todos han terminado. La garantía temporal que a spawn le faltaba, aquí es estructural, y el compilador la convierte en un lifetime en el que confiar.

El precio del ’static y cómo scope lo evita

Recuerda por qué spawn pedía 'static: el hilo hijo podía sobrevivir a la función que lo lanzó, así que prestar de su pila daba una referencia colgante. Pero ese peligro solo existe si el hilo puede sobrevivir al padre. thread::scope elimina esa posibilidad de raíz con una promesa: la llamada no retorna hasta que todos los hilos lanzados en el ámbito han terminado (se les hace join automáticamente al cerrar). Si el padre no puede avanzar más allá del scope mientras haya hilos vivos, entonces la pila del padre está garantizada viva durante toda la vida de esos hilos, y prestar de ella es sólido.

La firma del spawn de un ámbito refleja el cambio en una sola palabra:

// Metodo de Scope<'scope, 'env>, conceptualmente:
pub fn spawn<F, T>(&'scope self, f: F) -> ScopedJoinHandle<'scope, T>
where
    F: FnOnce() -> T + Send + 'scope,   // 'scope, no 'static
    T: Send + 'scope,

Donde thread::spawn exigía 'static, Scope::spawn exige 'scope: los datos prestados solo tienen que vivir tanto como el ámbito, no tanto como el programa. Esa rebaja quirúrgica es todo lo que hace falta.

thread::scope: prestar de la pila del padre

El ejemplo que spawn rechazaba —dos hilos leyendo un Vec local— aquí compila sin move, sin Arc y sin clonar, porque los hilos simplemente prestan &datos:

use std::thread;

fn main() {
    let datos = vec![1, 2, 3, 4, 5];
    let objetivo = 3;

    thread::scope(|s| {
        s.spawn(|| {
            let suma: i32 = datos.iter().sum();       // presta &datos
            println!("suma: {suma}");
        });
        s.spawn(|| {
            let hay = datos.contains(&objetivo);      // presta &datos y &objetivo
            println!("contiene {objetivo}: {hay}");
        });
    }); // <- aqui se hace join de ambos hilos automaticamente

    println!("datos sigue vivo: {datos:?}");   // no se movio, solo se presto
}

Dos hilos comparten &datos a la vez —muchos lectores, ningún escritor: alias sin mutación, permitido—. Y como scope no retorna hasta que ambos acaban, el println! final vuelve a usar datos intacto: nunca se movió, solo se prestó. Compara con la lección uno, donde compartir un Vec de solo lectura obligaba a clonar o a envolver en Arc; el ámbito lo vuelve innecesario.

Reparto mutable disjunto

Lo verdaderamente potente llega con la mutación. Compartir un &mut entre hilos sigue prohibido —sería alias más mutación—, pero se pueden partir los datos en fragmentos que no se solapan y dar a cada hilo el suyo. Métodos como split_at_mut o chunks_mut producen varios &mut disjuntos, y como no se solapan, cada uno tiene un único escritor y la regla se respeta:

use std::thread;

fn main() {
    let mut v = vec![0i32; 8];
    let (izq, der) = v.split_at_mut(4);   // dos &mut que no se solapan

    thread::scope(|s| {
        s.spawn(move || {
            for x in izq.iter_mut() { *x += 1; }   // este hilo posee la mitad izquierda
        });
        s.spawn(move || {
            for x in der.iter_mut() { *x += 2; }   // el otro, la derecha
        });
    });

    println!("{v:?}");   // [1, 1, 1, 1, 2, 2, 2, 2]
}

Cada hilo recibe por move un &mut [i32] distinto —una referencia mutable no estática, que spawn habría rechazado y que scope acepta porque solo vive dentro del ámbito—. No hay alias: izq y der cubren zonas de memoria ajenas, así que dos escritores simultáneos jamás tocan la misma dirección. El compilador verifica la disyunción a través de split_at_mut (cuya firma promete devolver mitades que no se solapan) y deja correr la mutación paralela sin Mutex ni sincronización de ninguna clase. Paralelismo de datos real, comprobado en compilación.

flowchart TD
E[Variables en la pila del padre] --> SC[thread scope abre un ambito]
SC --> T1[Hilo 1 presta datos del padre]
SC --> T2[Hilo 2 presta datos del padre]
T1 --> B[scope no retorna hasta que ambos terminan]
T2 --> B
B --> R[Recien entonces el padre continua]
R --> V[Ningun prestamo sobrevive a los datos prestados]
style SC fill:#89b4fa,color:#11111b
style B fill:#cba6f7,color:#11111b
style V fill:#a6e3a1,color:#11111b