Stream: git-wasmtime

Topic: wasmtime / issue #10667 Async Yield may immediately resch...

Wasmtime GitHub notifications bot (Apr 24 2025 at 16:27):

posborne added the bug label to Issue #10667.

Wasmtime GitHub notifications bot (Apr 24 2025 at 16:27):

posborne opened issue #10667:

Credit to @aturon for the discovery...

Today, the async_yield_impl behavior triggered an epoch deadline is hit or we run out of fuel does not match that of tokio::task::yield_now. They are _mostly_ the same except that with the current implementation that wasm task effectively gets immediately rescheduled (it is not deferred and ends up at the front rather than the back of the pending queue). This would not necessarily be the case with all task schedulers but is the case with tokio today in its default configuration with the lifo-slot enabled (see tokio::runtime::Builder::disable_lifo_slot).

When targeting tokio, it would be preferred to have the async yield behavior map directly to whatever tokio::task::yield_now does. There seems to be a couple ways to approach this:

1. Feature flagging to enable the direct call.
2. Allow embedder to configure the async yield behavior to allow for yield_now to be called.

Secondarily, even if the lifo-slot was disabled, the yield_now behavior in tokio has the added benefit of not allowing the yielding task to be immediately stolen as it is first moved to the deferred queue. If the current worker does not end up picking up other blocking work then we'll end up resuming on the same thread and avoid potential thrashing.

Wasmtime GitHub notifications bot (Apr 24 2025 at 16:31):

fitzgen commented on issue #10667:

We jsut talked about this in the Wasmtime biweekly.

Gist was that we already support calling a callback at epoch interruption points and it makes sense to add an async variation of this callback API. This would allow embedders to call tokio::task::yield_now() from that async callback, while keeping the core of wasmtime free of any assumptions of which particular async executor is being used.

Wasmtime GitHub notifications bot (May 01 2025 at 16:15):

posborne closed issue #10667:

Credit to @aturon for the discovery...

Today, the async_yield_impl behavior triggered an epoch deadline is hit or we run out of fuel does not match that of tokio::task::yield_now. They are _mostly_ the same except that with the current implementation that wasm task effectively gets immediately rescheduled (it is not deferred and ends up at the front rather than the back of the pending queue). This would not necessarily be the case with all task schedulers but is the case with tokio today in its default configuration with the lifo-slot enabled (see tokio::runtime::Builder::disable_lifo_slot).

When targeting tokio, it would be preferred to have the async yield behavior map directly to whatever tokio::task::yield_now does. There seems to be a couple ways to approach this:

1. Feature flagging to enable the direct call.
2. Allow embedder to configure the async yield behavior to allow for yield_now to be called.

Secondarily, even if the lifo-slot was disabled, the yield_now behavior in tokio has the added benefit of not allowing the yielding task to be immediately stolen as it is first moved to the deferred queue. If the current worker does not end up picking up other blocking work then we'll end up resuming on the same thread and avoid potential thrashing.

Last updated: Dec 06 2025 at 06:05 UTC