-
Notifications
You must be signed in to change notification settings - Fork 17.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
syscall: define SIGTERM for WASM #28719
Comments
Thank you for filing this issue and welcome to the Go project @elgohr! I'll kindly /cc some experts @ianlancetaylor @neelance |
Thanks for filing this. One one hand, there is the Go proverb "Syscall must always be guarded with build tags." (https://go-proverbs.github.io/), so code shouldn't expect On the other hand, the signal I would be okay with adding a dummy for Linking it to |
Some more thoughts - should SIGTERM close the window ? Or rather exit from the WASM session ? The signal is sent to the wasm binary, not the browser tab, so I think it is a bit unexpected to close the entire browser tab. A webapp may have multiple wasm applications running, so sending SIGTERM to one should not close all of them IMO. |
@agnivade As mentioned above, wasm/js (or WebAssembly itself) has no real support for signals at all, so I don't see how what you wrote fits in. |
Ah ! Sorry about that. Adding a dummy makes sense to me. We should not go about taking any action until the wasm spec properly supports signals. |
There is the |
Change https://golang.org/cl/150477 mentions this issue: |
The js/wasm architecture does not support signals at all, but there are already some signal constants defined because of stdlib dependencies. This change adds a dummy constant for syscall.SIGTERM as well, to make js/wasm compatible with more existing Go code. There is the Go proverb "Syscall must always be guarded with build tags.", so code should not expect syscall.SIGTERM to exist. Still, adding SIGTERM should do more good than harm. Fixes #28719. Change-Id: I3554b484f96a21427491c04eb1dd57e7af5bd62f Reviewed-on: https://go-review.googlesource.com/c/150477 Run-TryBot: Richard Musiol <neelance@gmail.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org>
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
I tried to use syscall.SIGTERM in
GOOS=js GOARCH=wasm
.Various libraries, for example see onsi/ginkgo#532 , are listening on syscall.SIGTERM.
As syscall.SIGTERM is not defined in WASM right now,
$ GOOS=js GOARCH=wasm go test
results in an error.spec_runner.go:220:33: undefined: syscall.SIGTERM
On the other hand, running
$ go test
results in an error, assyscall/js
is only available when usingGOOS=js GOARCH=wasm
What did you expect to see?
I would expect syscall.SIGTERM to be defined as window.unload (https://developer.mozilla.org/de/docs/Web/Events/unload)
What did you see instead?
The text was updated successfully, but these errors were encountered: