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: async preemption (or alternative) for wasm #71134

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

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

prattmic opened this issue Jan 6, 2025 · 3 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

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
@Zxilly
Copy link
Member

Zxilly commented Jan 11, 2025

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

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
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. NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
Status: No status
Development

No branches or pull requests

3 participants