Workers: thread isolation and the Guillotine
How Link Loom runs untrusted and CPU-heavy code in dedicated V8 isolates — and why forceful termination is a feature.
There are two kinds of code you should never run on your main event loop: code that is expensive, and code you did not write. Link Loom Workers exist for both.
Each worker runs in a Node.js worker thread with its own V8 heap. Variables are private. Memory is isolated. A crash in the worker is an event the host observes — not one it suffers.
A lifecycle you can hold in your head
Every worker instance moves through a strict state machine: INACTIVE → ACTIVE_FOREGROUND / ACTIVE_BACKGROUND → SUSPENDED → TERMINATING → TERMINATED. Each instance has a pid and an alias, addressable globally or by name. The commands are the API: spawn, activate, suspend, resume, signal, stop.
The Guillotine
The most important design decision in the workers module is what happens at the end. When a worker completes or is stopped, the proxy calls worker.terminate() — V8 halts the isolate and the operating system reclaims 100% of the memory that thread allocated. No lingering closures, no slow leaks accumulating across jobs. Ephemeral workers stay ephemeral.
No crossed wires
Communication uses a correlation-ID protocol: every command carries a monotonic message id, and the response resolves exactly the promise that sent it. You can have a stop in flight while an activate returns and nothing gets mixed up.
The result is a primitive you stop thinking about: hand it the PDF parse, the third-party integration, the thousand nightly jobs — and keep your event loop for the work that needs to be fast.
