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

wasi_snapshot_preview2 - lack of sched_yield interface #582

Open
loganek opened this issue Feb 9, 2024 · 5 comments
Open

wasi_snapshot_preview2 - lack of sched_yield interface #582

loganek opened this issue Feb 9, 2024 · 5 comments

Comments

@loganek
Copy link

loganek commented Feb 9, 2024

Hi all,

I'm looking to migrate some of the WSP1 code to WSP2 and I noticed there's no sched_yield equivalent in any of the existing world launched here: #577. Is this functionality covered by any of the existing proposals? I'm not sure if that's in scope of the https://github.com/WebAssembly/shared-everything-threads proposal, but even if so, the proposal is in a very early stage right now, but WSP2 is already launched.

My assumption was that WSP1 can be implemented using WSP2 (not other way around though) and that assumption was confirmed yesterday during the WASM64 discussion. I wonder if lack of the interface is simply a miss or was it deliberately omitted?

Thanks

@lukewagner
Copy link
Member

I expect it was just an omission, but I do increasingly think (especially in concurrent composition scenarios like we're considering for Preview 3) that a cooperative "yield" call is pretty important, so maybe this could be a candidate for inclusion in the short term (wasi:io seems like the right place) as part of 0.2.1?

@lukewagner
Copy link
Member

I suppose one short-term 0.2.0 workaround (which is not ideal, but probably gives the runtime what it needs to perform a cooperative yield) is to implement sched_yield with a wasi:io/poll.poll waiting on a pollable produced by wasi:clocks/monotonic-clock.subscribe-duration(0).

@pchickey
Copy link
Contributor

pchickey commented Feb 9, 2024

Agree with Luke -we omitted sched_yield because we weren't aware of any Preview 1 implementations or programs making strategic use of it, and didn't want to commit ourselves to something before we understood how its use would fit in with the rest of wasi-io and whatever other concurrency plans are upcoming in preview 3. Polling on an elapsed timer is a fine polyfill for now, and we'll add something more appropriate as the design space gets fleshed out better.

@sunfishcode
Copy link
Member

Another reasonable polyfill is to have sched_yield do nothing.

As background here, sched_yield was derived from CloudABI. We defaulted to leaving it in because it was easy to implement and it didn't seem to have any obvious complications. However, I'm not aware of any meaningful use cases for it, especially since WASIp2 doesn't support threads yet.

@loganek
Copy link
Author

loganek commented Mar 17, 2024

I think it'd be helpful for projects that continue using wasi threads with preview 2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants