wasmtime / PR #13246 Track whether there are any async ta... · git-wasmtime

Stream: git-wasmtime

Topic: wasmtime / PR #13246 Track whether there are any async ta...

Wasmtime GitHub notifications bot (Apr 30 2026 at 22:56):

alexcrichton requested dicej for a review on PR #13246.

Wasmtime GitHub notifications bot (Apr 30 2026 at 22:56):

alexcrichton opened PR #13246 from alexcrichton:poll-tasks-in-a-store to bytecodealliance:main:

This commit adds a new API to Accessor to learn whether there are any async tasks that are "interesting" in a store. This is borne out of many discussions over the past few weeks amongst a number of folks where the basic problem is that for WASIp3 HTTP guests there's no way right now to send a signal of "keep me alive after I send my response" because that's post-return-style work. In WASIp2 this was modeled where the outparam that was passed in was set, and then work was done before returning. With WASIp3, however, a response is sent by returning which means that this is no longer possible.

The general idea is that Wasmtime will now consider all tasks which have not yet exited as "interesting". These tasks in theory mean that the store should be kept alive as the guest still has work to complete. Note that tasks first return, and then exit, and they're still considered interesting after returning before they exit. In the future it's expected that the component model might have an ABI option to say "this task, by default, isn't interesting" with an opt-in method at runtime of saying "ok wait but yes this is interesting". In this manner it's expected that not all tasks for all of time will be considered interesting, only those that are intentionally opted-in to being interesting (and today that just so happens to be all of them).

The API itself on Accessor is a poll_*-style function which enables both checking to see if there are no more tasks remaining as well as registering a callback to get notified when there are actually no more tasks remaining. In this manner HTTP servers can await this as one of the events that concludes when a guest is finished processing.

The implementation of this API required some refactoring of concurrent.rs. Namely I wanted to have a relatively "narrow waist" through which increments/decrements of this internal counter happened to ensure that nothing was forgot. This is a bit non-trivial because there are a number of situations which means that a task is "exited", such as:

A synchronously lifted function returns.

An asynchronously lifted function returns CALLBACK_CODE_EXIT.

An asynchronously lifted function is stuck in the STARTING state, and then gets cancelled.

A task is running, is then cancelled, acknowledges the cancellation, and then exits.

A task with threads exits without actually returning, and then one of its threads returns for it.

For now the logic of "are interesting tasks done" is now hooked into cleanup_thread. This will likely require adjusting in the future for threads because in this last bullet the task.return invocation is the point where all conditions are met (main thread exited, task returned) as opposed to when the thread itself exits. For now though this is intended to be as close an approximation as possible.

Throughout this implementation I've performed a number of refactorings to reduce duplication, shuffle where methods are implemented, reduce some verbosity, etc. There are debug assertions in place for if this predicate ever goes wrong, which is intended to assist during development.

Wasmtime GitHub notifications bot (Apr 30 2026 at 22:56):

alexcrichton requested wasmtime-wasi-reviewers for a review on PR #13246.

Wasmtime GitHub notifications bot (Apr 30 2026 at 22:56):

alexcrichton requested wasmtime-core-reviewers for a review on PR #13246.

Wasmtime GitHub notifications bot (Apr 30 2026 at 23:04):

alexcrichton updated PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 04:02):

github-actions[bot] added the label wasmtime:api on PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:thumbs_up: dicej submitted PR review.

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:speech_balloon: dicej created PR review comment:

                    // `Store`; once that call finishes, the first thing we need

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:speech_balloon: dicej created PR review comment:

Doc todos.

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:speech_balloon: dicej created PR review comment:

Are we concerned about overflow here, e.g. on 32-bit systems where the guest could conceivably reach usize::MAX with a whole bunch of guest-to-guest calls?

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:speech_balloon: dicej created PR review comment:

I'm having trouble understanding this TODO and how it would be actionable.

Wasmtime GitHub notifications bot (May 01 2026 at 14:58):

:speech_balloon: dicej created PR review comment:

FYI, I've approached this differently with my recent refactoring of this module (which will unfortunately conflict somewhat with these changes). I've changed HandlerState::idle_instance_timeout to return a impl Future<Output = ()> + 'static + Send + Sync instead of a Duration, giving the implementation the opportunity to cull idle instances early if needed (e.g. if other instantiations for other apps have failed due to pooling allocator limits). Won't be a problem; just wanted to mention it.

Wasmtime GitHub notifications bot (May 01 2026 at 17:38):

alexcrichton updated PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 17:39):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (May 01 2026 at 17:39):

:speech_balloon: alexcrichton created PR review comment:

Oh sorry this was a transient note to myself I forgot to remove

Wasmtime GitHub notifications bot (May 01 2026 at 17:42):

alexcrichton updated PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 17:45):

:speech_balloon: alexcrichton created PR review comment:

Personally I think that's fine, if we get anywhere close to usize::MAX calls then I'd assume each call would take more than 1 or 2 bytes so we'd probably run out of memory long before that

Wasmtime GitHub notifications bot (May 01 2026 at 17:45):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (May 01 2026 at 17:46):

:memo: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (May 01 2026 at 17:46):

:speech_balloon: alexcrichton created PR review comment:

Joel and I talked a bit more about this and we concluded that the new "timeout future" should still slot in well.

Joel I'm going to go ahead and flag this PR for merge, but I'm also happy to help work through any merge conflicts if they become too onerous.

Wasmtime GitHub notifications bot (May 01 2026 at 17:46):

alexcrichton has enabled auto merge for PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 20:03):

alexcrichton updated PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 20:18):

alexcrichton added PR #13246 Track whether there are any async tasks in a store to the merge queue.

Wasmtime GitHub notifications bot (May 01 2026 at 20:46):

:check: alexcrichton merged PR #13246.

Wasmtime GitHub notifications bot (May 01 2026 at 20:46):

alexcrichton removed PR #13246 Track whether there are any async tasks in a store from the merge queue.

Last updated: May 03 2026 at 22:13 UTC