wasmtime / issue #13040 [wasi-io] polling (p2) or `waitab... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / issue #13040 [wasi-io] polling (p2) or `waitab...

Wasmtime GitHub notifications bot (Apr 10 2026 at 19:16):

dicej assigned dicej to issue #13040.

Wasmtime GitHub notifications bot (Apr 10 2026 at 19:16):

While debugging https://github.com/tokio-rs/tokio/issues/8034, @alexcrichton and I determined that wasmtime_wasi's wasi:clocks/monotonic-clock#{subscribe_instant,subscribe_duration,wait_until,wait_for implementations can cause starvation when combined with wasi:io/poll#poll (for WASIp2) or waitable-set.wait (for WASIp3). 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.

Wasmtime GitHub notifications bot (Apr 10 2026 at 19:16):

dicej added the bug label to Issue #13040.

Wasmtime GitHub notifications bot (Apr 10 2026 at 19:16):

dicej added the wasi:impl label to Issue #13040.

Wasmtime GitHub notifications bot (Apr 10 2026 at 19:20):

dicej edited issue #13040:

While debugging https://github.com/tokio-rs/tokio/issues/8034, @alexcrichton and I determined that wasmtime_wasi's wasi:clocks/monotonic-clock#{subscribe_instant,subscribe_duration,wait_until,wait_for} implementations can cause starvation when combined with wasi:io/poll#poll (for WASIp2) or waitable-set.wait (for WASIp3). 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.

Wasmtime GitHub notifications bot (Apr 10 2026 at 23:33):

dicej commented on issue #13040:

In https://github.com/dicej/wasmtime/commit/cf7f9f725583ab698be810e350fd549ccd08f7e6 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.

Wasmtime GitHub notifications bot (Apr 11 2026 at 10:12):

Darksonn commented on issue #13040:

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.

Last updated: Apr 12 2026 at 23:10 UTC