I’m currently experimenting with running (multi-threaded) Emscripten/Wasm-Code in a SharedWorker. While this works reasonably well for single-threaded code (running Emscripten’s JS code and Wasm code all in a single SharedWorker instance), there’s challenges for multi-threaded code, requiring support for SharedArrayBuffer from within a SharedWorker.
Out of the box, I don’t get SharedWorkerGlobalScope to provide access to SharedArrayBuffer (even with the usual Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp HTTP headers) at all. (Creating a WebAssembly.Memory with shared: true would nevertheless work, but then trying to send that WebAssembly.Memory to another Worker via postMessage would fail, throwing a terse Error: undefined.)
I found that nightly builds of Firefox allow setting om.postMessage.sharedArrayBuffer.bypassCOOP_COEP.insecure.enabled, which would make things work nicely.
However, without that overriding flag, the code appears to not be meant to support SharedArrayBuffer in a SharedWorker, in any way: RemoteWorkerChild::ExecWorkerOnMainThread (in dom/workers/remoteworkers/RemoteWorkerChild.cpp) calls WorkerPrivate::Constructor (in dom/workers/WorkerPrivate.cpp), which calls WorkerPrivate::ComputeAgentClusterIdAndCoop, which for aWorkerKind == WorkerKind::WorkerKindShared will unconditionally return an nsILoadInfo::CrossOriginOpenerPolicy of nsILoadInfo::OPENER_POLICY_UNSAFE_NONE. Which means that a later call to WorkerPrivate::IsSharedMemoryAllowed will fall through to WorkerPrivate::CrossOriginIsolated, which will always return false as mAgentClusterOpenerPolicy is not nsILoadInfo::OPENER_POLICY_SAME_ORIGIN_EMBEDDER_POLICY_REQUIRE_CORP.
Am I out of luck here, or is there a way in which a SharedWorker would support SharedArrayBuffer (if not today, then at least in the planned future)?