Multithreading in WASM - how did that come out?

help
1

Back in 2018, true multi-threading in Rust targeted to WASM seemed close. What happened? The thread spec for WASM does get occasional updates, so this isn't totally dead.

For a while, multithreading in the browser was a bad idea because of the SPECTRE exploit. But most CPUs after 2019 aren't vulnerable, and four years later, this is much less of a problem.

So is there work going on in this area?

(I don't mean using web workers and multiple processes. I'd like to move something with lots of fine-grained locking to a browser in the next year or two, for which I'd need real threading.)

3 Likes
2
2 Likes
3

WASM Threads are Phase 3 (implementation phase), so it's in the appropriate phase for implementing and experimental use (but not for production use).

For Rust specifically, a large difficulty is that the wasm32-unknown-unknown target has gotten a lot of code presuming it to be single-threaded. It might be necessary to split out a separate target so that's not an issue. Notably, we want std types like Mutex to continue "working" on just the wasm 1.0 set of target features.

It might be sufficient to expose/configure wasm thread support via cfg(target_feature); I have no idea.

Note that wasi+threads isn't sufficient for OP, since they specifically mentioned targeting the browser.

5 Likes
4

Ugh.

5

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.