Wasmtime GitHub notifications bot (May 29 2026 at 20:40): Wasmtime GitHub notifications bot (May 29 2026 at 20:40):alexcrichton requested dicej for a review on PR #13511.
Wasmtime GitHub notifications bot (May 29 2026 at 20:40):alexcrichton opened PR #13511 from alexcrichton:fix-p2-zero-wait to bytecodealliance:main:
This commit fixes an accidental bug introduced in #13085 where repeatedly calling
ready()on a zero-wait pollable in WASIp2 would never resolve. In #13085 zero-length waits were updated to unconditionally yield to tokio to improve fairness, but this didn't take into account where the yield was repeatedly cancelled and never completed. The fix in this commit is to attempt the yield once and then never attempt it again. If the original yield is cancelled the next check on the pollable will go through. This is sort of a cancellation-safety fix where the previous implementation wasn't necessarily cancellation safe in the sense that repeatedly checking-and-cancelling never let anything progress, which is counterintuitive.Closes #13507
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (May 29 2026 at 20:40):alexcrichton requested wasmtime-core-reviewers for a review on PR #13511.
Wasmtime GitHub notifications bot (May 29 2026 at 20:40):alexcrichton requested wasmtime-wasi-reviewers for a review on PR #13511.
Wasmtime GitHub notifications bot (May 29 2026 at 20:55):alexcrichton updated PR #13511.
Wasmtime GitHub notifications bot (May 29 2026 at 22:09):alexcrichton updated PR #13511.
Wasmtime GitHub notifications bot (May 29 2026 at 23:05):github-actions[bot] added the label wasi on PR #13511.
Wasmtime GitHub notifications bot (Jun 01 2026 at 08:59)::memo: ignatz submitted PR review.
Wasmtime GitHub notifications bot (Jun 01 2026 at 08:59)::speech_balloon: ignatz created PR review comment:
I'm primarily commenting to say: "Thank you" :folded_hands: and secondarily in a selfish attempt to better understand what's going on, i.e. from a place of ignorance.
I understood from your text that Pollable::ready is called multiple time and I would have absolutely written the code in the same way it was, i.e. it's surprising to me that the status quote cannot make progress. Wouldn't all futures returned by yield_now get resolved eventually even if some of them get dropped?
Since I don't even have the context why Pollable::ready gets called multiple times, I'm wondering if this can lead to some re-ordering of tasks? First call will yield, second won't which means a second continuation may get scheduled earlier than the first. This is probably not an issue since tokio doesn't give any ordering guarantees but may still be surprising :shrug:.
Maybe there's some way in the downstream consuming code to address this issue rather than the conditional yielding? Then again, I've no clue and you should do what makes the most sense.
From a mere user's perspective, I would expect repeated yields from WASM to lead to repeated yields to the tokio runtime ... as long as that's the case :woman_shrugging:
Last updated: Jun 01 2026 at 09:49 UTC