go
go copied to clipboard
cmd/compile: thread support for webassembly
What version of Go are you using (go version
)?
$ go version go version go1.11.1 darwin/amd64
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env
)?
go env
Output
$ go env GOARCH="amd64" GOBIN="" GOCACHE="/Users/sion/Library/Caches/go-build" GOEXE="" GOFLAGS="" GOHOSTARCH="amd64" GOHOSTOS="darwin" GOOS="darwin" GOPATH="/Users/sion/go1.X" GOPROXY="" GORACE="" GOROOT="/usr/local/go" GOTMPDIR="" GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64" GCCGO="gccgo" CC="clang" CXX="clang++" CGO_ENABLED="1" GOMOD="" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/6z/bfzgs4bs75bdjmr9c7dggct40000gn/T/go-build090156779=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
It is very nice to use goroutine browsers, WebAssembly Threads ready to try in Chrome 70. I found no related issues here, so i just add this issue.
What did you expect to see?
Thread feature supported in xx.wasm.
What did you see instead?
Not supported in chromium 72.
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 https://github.com/WebAssembly/threads/issues/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.
Given that threads are enabled in all major browsers it seems work on this is now worthwhile.