polling with a zero timeout (p2) or `waitable-set.poll`ing (p3) can starve the async runtime

[dicej]

While debugging tokio-rs/tokio#8034, @alexcrichton and I determined that wasmtime_wasi's wasi:clocks/monotonic-clock#{subscribe_instant,subscribe_duration} implementations can cause starvation when combined with wasi:io/poll#poll (on WASIp2). Likewise, on WASIp3, Wasmtime's waitable-set.poll implementation does not currently yield to the async runtime. Because those implementations do not yield at all for zero-duration waits, and because tokio::task::yield_now in guest code will poll with a zero timeout, the host will not yield to it's tokio runtime and give mio a chance to report readiness for one of the other pollables.

The solution is for the host (i.e. wasmtime_wasi) to call tokio::task::yield_new().await in that scenario before returning control to the guest to give mio a chance to run.

[dicej]

In dicej@cf7f9f7 I've added tests which reliably reproduce the issue for both p2 and p3, and a fix for p2, but I'm not sure yet how to address p3 given that Wasmtime doesn't depend on Tokio, so we can't just call tokio::task::yield_now there. One thought would be to add a public API so the embedder can supply their own yield function.

[Darksonn]

It's worth clarifying that when Tokio yields with a duration of zero, the express purpose of doing that is to get new IO events, so I think it's important that WASI will check for them and deliver them in that scenario.

[alexcrichton]

@dicej for wasip3, could a "store locking yield" be done for waitable-set.poll? That way it doesn't affect wasm semantics at all, it can be done without depending on tokio, and it should serve the purpose of hitting the event loop and letting Tokio generate events.