Does this issue reproduce with the latest release?
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, as syscall/js is only available when using GOOS=js GOARCH=wasm
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.
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.
Run-TryBot: Richard Musiol <email@example.com>
Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.org>
TryBot-Result: Gobot Gobot <email@example.com>