Go: syscall: define SIGTERM for WASM

[elgohr]

What version of Go are you using (go version)?

$ go version
go version go1.11 linux/amd64

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 https://github.com/onsi/ginkgo/issues/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

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?

github.com/onsi/ginkgo/internal/specrunner
../../../../../pkg/mod/github.com/onsi/[email protected]/internal/specrunner/spec_runner.go:220:33: undefined: syscall.SIGTERM
../../../../../pkg/mod/github.com/onsi/[email protected]/internal/specrunner/spec_runner.go:245:33: undefined: syscall.SIGTERM

[odeke-em]

Thank you for filing this issue and welcome to the Go project @elgohr!

I'll kindly /cc some experts @ianlancetaylor @neelance

[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 syscall.SIGTERM to exist.

On the other hand, the signal SIGTERM is very common and there are already some other signals defined for wasm/js because of stdlib dependencies.

I would be okay with adding a dummy for SIGTERM. wasm/js currently does not support signals at all, but it might help with compatibility like in the case mentioned above.

Linking it to window.unload is probably not a good idea, since the semantics are different. SIGTERM means "please exit", window.unload means "exiting now".

[agnivade]

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.

[neelance]

@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.

[agnivade]

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.

[nlepage]

Linking it to window.unload is probably not a good idea, since the semantics are different. SIGTERM means "please exit", window.unload means "exiting now".

There is the beforeunload event which would be a better fit, it is fired "when the window, the document and its resources are about to be unloaded".

[gopherbot]

Change https://golang.org/cl/150477 mentions this issue: syscall: add dummy SIGTERM constant to js/wasm