I guess it would have been done anyways at some point. But thanks for filing an issue.

Related: #28360 on the policy of adopting new WebAssembly features.

I will wait at least until the proposal gets to phase 3 before I start working on it: https://github.com/WebAssembly/proposals

Although the proposal is not yet officially in phase 3, most major browsers (with the exception of Safari) have been shipping with WASM threads enabled for the past few versions.

https://www.chromestatus.com/feature/5724132452859904
https://bugzilla.mozilla.org/show_bug.cgi?id=1389458

Note that using WASM threads does require setting some HTTP headers due to Spectre:

https://caniuse.com/sharedarraybuffer

I suggest that support for threads be added to Go with a GOWASM=threads (or similar) compiler option, like how satconv and signext are currently implemented.

Any news?

@BenLubar is multi threading supported by modern browsers when compiling go into wasm ? Or when is this proposal to be added ?

I will wait at least until the proposal gets to phase 3 before I start working on it: https://github.com/WebAssembly/proposals

Out of curiosity, how much effort do you anticipate this will require to implement, assuming the current proposal makes it to phase 3?

Has there been any updates regarding support for multi-threading in webassembly. I think this is the only feature missing right now and definitely it is really important. Wasm is useful mostly for heavy computations, because otherwise in most cases wasm is slower as the js dom operations are quite slow. But for heavy computations, multi threading is a must to have.

Due to this WebAssembly/threads#163, this proposal may never be stage 3. But according to the issue above, browsers already did their job.

Though rust is now first class citizen in wasm world, but I still think when go can support thread natively, go will be No.1 wasm player in more high level business code area.

Such a pity for not having multi threading support in go wasm. It renders most wasm application useless, as javascript I think will be faster (if not comparable) to go wasm.

It seems the thing blocking it from moving to phase 3 is tests. Is there someone with skills who would like to help?

Also see: https://github.com/WebAssembly/threads

It looks like they are planning to vote on whether to move the threads proposal into stage 3 later this month

Amazing news!

From my understanding, that proposal isn't really about threads. It's about atomics. Threads are supposed to be provided by the environment (WebWorkers for example).

Dropping in to say that Wasm Threads are now phase 3!

Change https://go.dev/cl/463743 mentions this issue: runtime: add wasm atomic operations

Any news on this?

Is it officially part of wasm spec now ?

Curious about this as well. What is needed?

Is something blocking this?

Threads are now Phase 4.