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.

Sign up for GitHub

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

Jump to bottom

runtime: async preemption (or alternative) for wasm #71134

Open
prattmic opened this issue Jan 6, 2025 · 4 comments
Open

runtime: async preemption (or alternative) for wasm #71134

prattmic opened this issue Jan 6, 2025 · 4 comments
Labels
arch-wasm WebAssembly issues compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Unplanned

Comments

@prattmic
Copy link
Member

prattmic commented Jan 6, 2025

This is split from #65178, as the specific scheduler bug was fixed.

Due to its single-threaded nature, js/wasm have no sysmon thread, and thus no asynchronous preemption. Thus the pitfalls of Go prior to asynchronous preemption apply: tight loops that fail to yield may delay scheduling indefinitely.

This is a tracking issue for problems due to the lack of asynchronous preemption. As noted in #36365, due to the lack of threading, asynchronous preemption isn't possible today, but perhaps could be with wasm threads? Or we could have an alternative scheme for js/wasm (such as adding preemption points to loops).

(Plan9 is also missing async preemption, but that simply needs an implementation)
@prattmic prattmic added NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. compiler/runtime Issues related to the Go compiler and/or runtime. labels Jan 6, 2025
@prattmic prattmic added this to the Unplanned milestone Jan 6, 2025
@prattmic prattmic mentioned this issue Jan 6, 2025
Closed
@cagedmantis cagedmantis mentioned this issue Jan 9, 2025
Closed
@Zxilly
Copy link
Member

Zxilly commented Jan 11, 2025 •
edited
Loading

I have two ideas, one idea is to reimplement sysmon in js and rely on asynchronous scheduling on the js side to run it, but this would require runtime to expose a lot of internal interfaces in wasm, and it would also take extra effort to keep the js implementation consistent with the go implementation.
Another idea could be to start pushing for wasm thread support, but given that this is a relatively new feature, we still need to make sure it functions properly without wasm thread support. Also, additional COOP and COEP headers need to be configured to enable SharedArrayBuffer, which makes deployment difficult.

@cherrymui
Copy link
Member

cherrymui commented Jan 14, 2025 •
edited
Loading

I agree that using Wasm threads is probably the way to go. I don't think this is urgent, so we can probably wait until wasm threads are generally available. If we need anything urgent in the mean time, we could insert manual preemption point in specific code paths.

(Plan9 is also missing async preemption, but that simply needs an implementation)

https://go.dev/cl/228893 (and the stack) was an attempt. The main difficulty is the lack of the equivalent of SA_RESTART, so I have to restart interrupted syscalls manually. Due the the low availability and stability of the builders, I was not able to test the changes successfully.

@cherrymui
Copy link
Member

This also applies to wasip1/wasm (not just js).

@cherrymui cherrymui changed the title runtime: async preemption (or alternative) for js/wasm runtime: async preemption (or alternative) for wasm Jan 17, 2025
@cherrymui cherrymui added the arch-wasm WebAssembly issues label Jan 17, 2025
@gopherbot
Copy link
Contributor

Change https://go.dev/cl/640195 mentions this issue: os: skip force the goroutine to be scheduled on WASM

gopherbot pushed a commit that referenced this issue Jan 22, 2025
@cagedmantis @gopherbot
os: force a goroutine to be scheduled on WASM

Verified

This commit was signed with the committer’s verified signature.
tilpner Till Höppner
GPG key ID: 6A13327225BE51F6
Verified
Learn about vigilant mode
5a46b17 
The TestRootConcurrentClose test can fail when GOARCH=WASM because of
goroutine starvation. The spawned goroutine will sometimes run in a
loop and never have the main goroutine be scheduled. This causes the
test to fail due to a timeout. This change forces the goroutine to be
scheduled with each iteration of the loop when  GOARCH=WASM.

For #71134
Fixes #71117

Change-Id: I4fb68907c9ac3b33bd0572d5e5db2974a3379191
Reviewed-on: https://go-review.googlesource.com/c/go/+/640195
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Auto-Submit: Carlos Amedee <carlos@golang.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
arch-wasm WebAssembly issues compiler/runtime Issues related to the Go compiler and/or runtime. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
Go Compiler / Runtime
Status: No status
Milestone
Unplanned
Development

No branches or pull requests
4 participants
@prattmic @gopherbot @cherrymui @Zxilly