I am unfamiliar with this project and only skimmed this post but if this uses Rust for the main binary blob it should be possible to have the main thread blob shared with the other threads even with the blocking.

The blog post cites the concern that malloc could block, however when Rust's standard library is compiled with support for atomics enabled the Rust allocator's locking implementation busy loops instead of waiting on the main thread.

See the comment in the Rust source here: https://github.com/rust-lang/rust/blob/77a4fb62f70c6ea05e182...

This means that if care is taken to avoid any other code that makes the main thread wait it should be possible to use a single shared binary instead of the more convoluted approach presented in the blog post.

▲

AgentME 2 hours ago | parent | next [-]

People in the WebAssembly standards group are recently considering relaxing the limitation that the main thread can't use atomic.wait: https://github.com/WebAssembly/threads/issues/177#issuecomme...

	▲	evmar an hour ago \| parent [-]
		Wow, thanks for the link, that is perfect timing! I submitted my post and my own feedback on the discussion: https://github.com/WebAssembly/shared-everything-threads/dis...

▲

evmar 2 hours ago | parent | prev [-]

Gosh, I think that means even when your code is wholly running on workers (where you would be able to use the atomic wait mentioned in the comment), it still will busy loop, doesn't it? At least it's within the allocator and not in the general implementation of Mutex... I think?

	▲	kettlecorn 27 minutes ago \| parent [-]
		Yes that first sentence is correct and that's an unfortunate side effect. The Rust ecosystem eventually needs to evolve its multithreaded Wasm approach. Atomics are still only supported on Nightly Rust but it's been that way for 7+ years now. And yes you're right again it's only in the allocator.