Stream: git-wasmtime

Topic: wasmtime / PR #12640 Fix/improve host subtask cancellation

Wasmtime GitHub notifications bot (Feb 23 2026 at 17:58):

alexcrichton opened PR #12640 from alexcrichton:fix-host-subtask-canel to bytecodealliance:main:

This commit refactors some of the internals of subtask.cancel with respect to host subtasks. Notably a few panics and semantic bugs are fixed here. The main bug was that host subtasks could be aborted but their completion might have still been queued up which would produce the result somewhere or assert that the task exists. Cancellation is changed to use wait_for_event to ensure that this completion is executed before subtask.cancel returns. This helps keep host subtasks looking more similar to guest subtasks in that respect.

Co-authored-by: Jelle van den Hooff <jelle@vandenhooff.name>

Closes #12631
Closes #12632

<!--
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 (Feb 23 2026 at 17:58):

alexcrichton requested cfallin for a review on PR #12640.

Wasmtime GitHub notifications bot (Feb 23 2026 at 17:58):

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

Wasmtime GitHub notifications bot (Feb 23 2026 at 17:58):

alexcrichton edited PR #12640:

This commit refactors some of the internals of subtask.cancel with respect to host subtasks. Notably a few panics and semantic bugs are fixed here. The main bug was that host subtasks could be aborted but their completion might have still been queued up which would produce the result somewhere or assert that the task exists. Cancellation is changed to use wait_for_event to ensure that this completion is executed before subtask.cancel returns. This helps keep host subtasks looking more similar to guest subtasks in that respect.

Closes #12631
Closes #12632

<!--
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 (Feb 23 2026 at 17:59):

alexcrichton updated PR #12640.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:00):

alexcrichton requested dicej for a review on PR #12640.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:00):

alexcrichton unassigned cfallin from PR #12640 Fix/improve host subtask cancellation.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:08):

jellevandenhooff commented on PR #12640:

thanks for the fast fix! I couldn’t quite tell from reading the code if this will change the subtask.cancel behavior: will a cancel in progress now require the caller to wait before dropping?

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:22):

dicej submitted PR review:

Thanks!

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:23):

alexcrichton commented on PR #12640:

Spec-wise subtask.cancel stays the same, so no changes there. Wasmtime is changing a bit semantically though (within the allowable behaviors of the spec) where previously cancellation of a host subtask would never block, but now it blocks waiting for the cancellation notifcation to actually get received. That doesn't require any new behaviors in the guest, however, and it's only exposed if the guest is using the async option on subtask.cancel which it in theory would already be handling anyway.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:23):

alexcrichton added PR #12640 Fix/improve host subtask cancellation to the merge queue.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:53):

jellevandenhooff commented on PR #12640:

Great, thanks. I was so far relying on cancel and then an immediate drop working, so I’ll have to become spec compliant in my guest. That is of course what the code should have done in the first place… but it will require some thinking because cancel+drop was a nice instantaneous cleanup path.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:58):

alexcrichton merged PR #12640.

Wasmtime GitHub notifications bot (Feb 23 2026 at 18:58):

alexcrichton removed PR #12640 Fix/improve host subtask cancellation from the merge queue.

Last updated: Feb 24 2026 at 04:36 UTC