wasi_snapshot_preview2 - lack of sched_yield interface
loganek opened this issue · 5 comments
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
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?
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).
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.
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.
I think it'd be helpful for projects that continue using wasi threads with preview 2.