Stream: git-wasmtime

Topic: wasmtime / issue #13040 polling with a zero timeout (p2) ...

Wasmtime GitHub notifications bot (Apr 13 2026 at 15:19):

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} 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.

Wasmtime GitHub notifications bot (Apr 13 2026 at 15:19):

dicej added the wasm-proposal:component-model-async label to Issue #13040.

Wasmtime GitHub notifications bot (Apr 13 2026 at 15:20):

alexcrichton commented on issue #13040:

@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.

Wasmtime GitHub notifications bot (Apr 14 2026 at 17:43):

dicej closed 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} 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.

Last updated: May 03 2026 at 22:13 UTC