Wasmtime GitHub notifications bot (Apr 24 2025 at 20:25): Wasmtime GitHub notifications bot (Apr 24 2025 at 20:25):posborne opened PR #10671 from posborne:custom-async-yield to bytecodealliance:main:
As described in
https://github.com/bytecodealliance/wasmtime/issues/10667, the yield future provided in-tree when a epoch callback cannot always trigger the specific behavior desired in async schedulers like tokio.This change introduces a new variant to the UpdateDeadline callback with the future implementing the desired task suspension behavior desired for yielding control within the async runtime.
Note that this change does not allow for controlling this behavior for fuel yielding at this time.
CC @aturon @fitzgen -- at first I looked at adding a separate async callback but this felt a little cleaner but happy to change things up. There's definitely some overhead here in needing to frequently do the future boxing so would be happy to look at other paths to optimize if we have concerns (though my gut says it shouldn't be _too_ bad).
<!--
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 (Apr 24 2025 at 20:25):posborne requested wasmtime-core-reviewers for a review on PR #10671.
Wasmtime GitHub notifications bot (Apr 24 2025 at 20:25):posborne requested fitzgen for a review on PR #10671.
Wasmtime GitHub notifications bot (Apr 24 2025 at 21:32):alexcrichton created PR review comment:
Drive-by-comment on this unrelated to this change, mind throwing
#[non_exhaustive]on this enum definition? That'll help consumers work with this a bit more nicely with the#[cfg]'d variants
Wasmtime GitHub notifications bot (Apr 24 2025 at 21:32):alexcrichton created PR review comment:
I realize this was probably copied from
async_yield_implbut nowadays I think we can dolet mut future = core::pin::pin!(future);to safely creatPin<Thing>and then with somefuture.as_mut()or such invocations I think it can safely createPin<&mut T>to pass here
Wasmtime GitHub notifications bot (Apr 24 2025 at 21:32):alexcrichton submitted PR review:
Seems like a reasonable API to me! I think it's fine to add similar configuration options for fuel in the future if necessary as a Fuel-specific configuration option
Wasmtime GitHub notifications bot (Apr 28 2025 at 19:25):posborne submitted PR review.
Wasmtime GitHub notifications bot (Apr 28 2025 at 19:25):posborne created PR review comment:
In this particular case, I think we can just change the type signature of the future to be a
Pin<Box<dyn Future ...>>>to avoid having to do anything extra to mark the memory as pinned.
Wasmtime GitHub notifications bot (Apr 28 2025 at 20:28):posborne updated PR #10671.
Wasmtime GitHub notifications bot (Apr 28 2025 at 20:49):posborne commented on PR #10671:
I considered adding a new API such as
epoch_deadline_async_yield_and_update_customor modifying the existing API to take a duration or duration + future-yielding callback but that felt pretty heavy. As-is, there's an option for embedders that have a need to customize the yield behavior but figured I would at least call things out.The tokio behavior is subtle enough to probably not rightly be able to be considered a bug and most use cases will probably not run into issues with the stock yield behavior.
Wasmtime GitHub notifications bot (Apr 28 2025 at 21:51):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 28 2025 at 22:13):alexcrichton merged PR #10671.
Last updated: Dec 06 2025 at 07:03 UTC