Skip to content
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

runtime: tight loops not preempted on wasm #60857

Closed
iansmith opened this issue Jun 17, 2023 · 5 comments
Closed

runtime: tight loops not preempted on wasm #60857

iansmith opened this issue Jun 17, 2023 · 5 comments
Labels
arch-wasm WebAssembly issues compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@iansmith
Copy link

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

@seankhliao seankhliao changed the title affected/package: runtime runtime: tight loops not preempted on wasm Jun 19, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Jun 19, 2023
@seankhliao seankhliao added the arch-wasm WebAssembly issues label Jun 19, 2023
@bcmills
Copy link
Contributor

bcmills commented Jun 20, 2023

See also #36365.

(CC @golang/wasm)

@dmitshur dmitshur added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 22, 2023
@dmitshur dmitshur added this to the Backlog milestone Jun 22, 2023
@mknyszek
Copy link
Contributor

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 mknyszek closed this as not planned Won't fix, can't repro, duplicate, stale Jun 28, 2023
@mknyszek
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arch-wasm WebAssembly issues compiler/runtime Issues related to the Go compiler and/or runtime. NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

7 participants
@iansmith @mknyszek @dmitshur @bcmills @gopherbot @seankhliao and others