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:
Wasmtime GitHub notifications bot (Jun 01 2026 at 14:19)::speech_balloon: ignatz edited PR review comment.
Wasmtime GitHub notifications bot (Jun 01 2026 at 14:39)::memo: alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jun 01 2026 at 14:39)::speech_balloon: alexcrichton created PR review comment:
The implementation of
pollable.ready(), which is what wstd is calling, creates thisPollable::readyfuture defined here, polls it, then drops it. With the previous implementation it would never make progress since the yield was attempted to happen every time. It looks like wstd never actually blocked on the pollable, it only kept asking if it was ready. This patched implementation still preserves yielding behavior, but the yield is only attempted once.
Wasmtime GitHub notifications bot (Jun 02 2026 at 14:40)::memo: dicej submitted PR review:
Thanks for doing this; LGTM. I want to go back and test https://github.com/tokio-rs/tokio/issues/8034 again with this code before approving to make sure it's still fixed with this update. I'll do that today.
Wasmtime GitHub notifications bot (Jun 02 2026 at 17:57):alexcrichton commented on PR #13511:
oh @dicej did you mean to check the "approved" box as well?
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:11):oh @dicej did you mean to check the "approved" box as well?
No, I wanted to retest the Tokio issue like I mentioned above. Will do that now.
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:12):alexcrichton commented on PR #13511:
Oh sorry, my reading comprehension apparently isn't the best today...
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:22)::thumbs_up: dicej submitted PR review:
Ok, the Tokio test is still be passing reliably with this change. Ship it!
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:31):alexcrichton added PR #13511 wasip2: Fix zero-wait pollables to the merge queue.
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:53):alexcrichton removed PR #13511 wasip2: Fix zero-wait pollables from the merge queue.
Wasmtime GitHub notifications bot (Jun 02 2026 at 22:53):alexcrichton added PR #13511 wasip2: Fix zero-wait pollables to the merge queue.
Wasmtime GitHub notifications bot (Jun 02 2026 at 23:17)::thumbs_up: dicej submitted PR review:
Ok, the Tokio test is still passing reliably with this change. Ship it!
Wasmtime GitHub notifications bot (Jun 02 2026 at 23:22)::check: alexcrichton merged PR #13511.
Wasmtime GitHub notifications bot (Jun 02 2026 at 23:22):alexcrichton removed PR #13511 wasip2: Fix zero-wait pollables from the merge queue.
Last updated: Jul 29 2026 at 05:03 UTC