WASMFS JS proxy thread assertion too strict

[JoeOsborn]

Right now, JS code in Module.onRuntimeInitialized can’t create certain WASMFS backends before main runs, which is something that’s possible in the JS filesystem and possible under wasmfs with JSPI. This is because e.g. fetchfs and opfs backends (as well as thread_util.h’s ProxyWorker) currently assert at construction time that they are either not on the main thread or they are running with JSPI.

The motivation behind these assertions is that the main thread may not be able to spawn a thread in a fresh worker without causing a deadlock, but sometimes it’s possible to do this safely (either to succeed or at least to fail if a worker is not available). Specifically, if the worker pool has a free unused worker, spawning a thread will definitely succeed.

While there is currently no api the C code could use to detect whether a worker is free, when run under PTHREAD_POOL_STRICT > 0 the worker fetching code will throw a warning (if strict = 1) or error out (if strict = 2) in the condition where a deadlock could happen by spawning a new worker from the main thread. I therefore think the assertions should be conditionally compiled in only when PTHREAD_POOL_STRICT is 0, and the overly strict condition now amounts to a bug.

[sbc100]

I would go one step further and say that it should be possible to make this work even without any workers in the pool. As long as the main thread is returning the to event loop and during async work during startup it should be possible to start new workers just fine.

It should be possible to do any amount of async work in onRuntimeInitialized, including starting new threads, as long you don't try to block on the new threads work before running the event loop.

[sbc100]

@tlively

[JoeOsborn]

Experimentally, chrome and Firefox have no problem with creating a backend from the browser thread during onRuntimeInitialized while Safari deadlocks.

[tlively]

It should be possible to do any amount of async work in onRuntimeInitialized

Sounds like another reason to add an async constructor for the OPFS backend.