Stream: git-wasmtime

Topic: wasmtime / PR #11720 remove `Trap::AsyncDeadlock`

Wasmtime GitHub notifications bot (Sep 19 2025 at 16:54):

dicej requested alexcrichton for a review on PR #11720.

Wasmtime GitHub notifications bot (Sep 19 2025 at 16:54):

dicej opened PR #11720 from dicej:no-more-async-deadlock to bytecodealliance:main:

Previously, Instance::run_concurrent returned this when all guest tasks and background host tasks had completed, and yet the future parameter it was passed still hadn't resolved. The theory was that this indicated a mistake on the host embedder's part, but it turns out there are scenarios where this is actually what the embedder wanted.

For example, consider a host embedder that implements a pool of worker tasks, each of which runs a loop inside async closure passed to Instance::run_concurrent. In this case, each worker accepts jobs (which involve calling guest functions) from a multiple-producer, multiple-consumer job queue, adding them to a futures::stream::FuturesUnordered so they can be run concurrently. When all the jobs accepted by a given worker have finished, there may be a lull during which no new jobs are yet available. In that case, the worker _could_ break out of the loop, resolve the future, allow Instance::run_concurrent to finish, and wait until the next job arrives before calling Instance::run_concurrent again, but that's more awkward (i.e. nested loops, complicated control flow) than just a single loop inside Instance::run_concurrent that goes idle now and then.

In short, the closure passed to Instance::run_concurrent might experience delays between when a set of guest tasks have completed and when the next set are ready to start, and that's not necessarily a bug.

<!--
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.html

Please ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->

Wasmtime GitHub notifications bot (Sep 19 2025 at 16:54):

dicej requested wasmtime-core-reviewers for a review on PR #11720.

Wasmtime GitHub notifications bot (Sep 19 2025 at 17:14):

alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 19 2025 at 17:19):

dicej has enabled auto merge for PR #11720.

Wasmtime GitHub notifications bot (Sep 29 2025 at 14:57):

dicej updated PR #11720.

Wasmtime GitHub notifications bot (Sep 29 2025 at 16:44):

dicej has disabled auto merge for PR #11720.

Wasmtime GitHub notifications bot (Sep 29 2025 at 16:44):

dicej closed without merge PR #11720.

Wasmtime GitHub notifications bot (Sep 29 2025 at 16:44):

dicej commented on PR #11720:

CI revealed that we have a number of WAST tests which rely on this trap, so simply removing it is not going to work. I'm going to close this and try a different approach.

Last updated: Dec 06 2025 at 07:03 UTC