runtime: tight loops not preempted on wasm

[iansmith]

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

$ go version
go version devel go1.21-dbf9bf2 Fri Jun 16 20:47:33 2023 +0000 linux/arm64

Does this issue reproduce with the latest release?

No, not exactly. The above version is "head" of the repo, which is not released yet.

If running on 1.20 on arm64/darwin, it does not reproduce. Running on the same release but with arm64/darwin it does not reproduce.

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

This only occurs with `wasm/wasip1` as the GOARCH and GOOS.

What did you do?

https://go.dev/play/p/-em2D-ypmWG?v=goprev

The above link works fine on prev release, current release, and dev release in go playground. The problem only appears when you are on wasm/wasip1 with 1.21 (head).

The program will not produce any output with either wasmtime or wazero as the host wasm environment. If you uncomment the calls to runtime.Gosched() you will see that one goroutine is created, so you see one line of output, but not two as you do with go playground.

What did you expect to see?

What is shown on go playground:

in go routine 1
in go routine 2
timeout running program

What did you see instead?

Nothing.

@neelance

[bcmills]

See also #36365.

(CC @golang/wasm)

[mknyszek]

Because Wasm doesn't have threads, there's no way for the runtime to preempt a running goroutine at all. On Wasm, this basically means all yields into the runtime need to be voluntary (channel operation, syscall, memory allocation, etc.).

I'm not sure there's anything we can do here until Wasm supports threads. Closing for now, but let me know if you disagree. Thanks!

[mknyszek]

Others have pointed out to me that it is technically possible for the compiler to insert yield points that say, has the goroutine check itself and how long its been running for on e.g. function entry and loop backedges. But this is likely to be prohibitively expensive on wasm platforms.