Workers: aislamiento por hilos y la Guillotina
Cómo Link Loom corre código pesado o no confiable en isolates V8 dedicados — y por qué la terminación forzada es un feature.
Hay dos tipos de código que nunca deberías correr en tu event loop principal: el código costoso, y el código que no escribiste tú. Los Workers de Link Loom existen para ambos.
Cada worker corre en un worker thread de Node.js con su propio heap V8. Las variables son privadas. La memoria está aislada. Un crash en el worker es un evento que el host observa — no uno que sufre.
Un ciclo de vida que cabe en la cabeza
Cada instancia de worker se mueve por una máquina de estados estricta: INACTIVE → ACTIVE_FOREGROUND / ACTIVE_BACKGROUND → SUSPENDED → TERMINATING → TERMINATED. Cada instancia tiene un pid y un alias, direccionable globalmente o por nombre. Los comandos son el API: spawn, activate, suspend, resume, signal, stop.
La Guillotina
La decisión de diseño más importante del módulo de workers es lo que pasa al final. Cuando un worker completa o se detiene, el proxy llama worker.terminate() — V8 detiene el isolate y el sistema operativo recupera el 100% de la memoria que ese hilo asignó. Sin closures colgando, sin fugas lentas acumulándose entre jobs. Lo efímero se mantiene efímero.
Sin cables cruzados
La comunicación usa un protocolo de correlation-ID: cada comando lleva un id monotónico de mensaje, y la respuesta resuelve exactamente la promesa que lo envió. Puedes tener un stop en vuelo mientras un activate retorna y nada se mezcla.
El resultado es una primitiva en la que dejas de pensar: entrégale el parseo del PDF, la integración de terceros, los mil jobs nocturnos — y quédate con tu event loop para el trabajo que necesita ser rápido.
