wasm-audio-worklet example faulty? Initializes 2nd thread in web context in which you can't block

[Nearoo]

Describe the Bug

In the docs for the wasm-audio-worklet you mention that the same caveats for the "parallel raytracing" apply. In those, you mention the following caveat:

Any thread launched after the first one might attempt to block implicitly in its initialization routine. This is a constraint introduced by the way we set up the space for thread stacks and TLS. This means that if you attempt to run a Wasm module in the main thread after you are already running it in a worker, it might fail.

Looking at the code of the wasm-audio-worklet example, you call in index.html:

import init, {web_main} from "./pkg/wasm_audio_worklet.js";
async function run() {
    await init();
    web_main();
}
run();

and then in worklet.js:

let [module, memory, handle] = options.processorOptions;
bindgen.initSync({ module, memory });

Like the main thread, the AudioWorklet is a context in which you can't block using Atomics.wait.

Could it be that the example is incorrect, and could in theory sporadically throw due to Atomics.wait being executed in the worklet node?

Steps to Reproduce

In theory, the example deployed here should throw sporadically, but we've been unable to observe it doing so.

Instead, we see it throwing regularly in our own project, which has a much more involved setup, with multiple threads spawning in:

• main thread
• some workers
• audio worklet processing node

We observe the initSync call in the worklet node throwing in particular if:

• the rust code is under "heavy load" (according to some hand wavy metrics & vibes)
• if running in Chrome under Windows (much more rarely on Linux & MacOS; other browsers aren't tested)

Expected Behavior

The example to be constructed in such a way that even with a more involved rust codebase, it never throws. Or at the very least, mention the caveat that the way the example is setup, it could throw sporadically.

Actual Behavior

It could throw sporadically, especially in more involved setups. The error looks something like this:

Uncaught RuntimeError: Atomics.wait cannot be called in this context
   at main.wasm:0x...
   at __wbg_finalize_init (main_wrapper.js:...)
   at Module.initSync (main_wrapper.js:...)
   at new WasmProcessor (...)

Additional Context

Summary of the above:

• issue doesn't happen in example, but in our own more involved project, that uses the same setup as the example
• our project spawns multiple threads, not just main & worklet
• happens more often "under heavy load"
• happens more often under windows
• only tested in chrome