Stream: git-wasmtime

Topic: wasmtime / PR #14382 update `subtask.cancel` implementati...

Wasmtime GitHub notifications bot (Sep 22 2026 at 22:54):

dicej requested alexcrichton for a review on PR #14382.

Wasmtime GitHub notifications bot (Sep 22 2026 at 22:54):

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

Wasmtime GitHub notifications bot (Sep 22 2026 at 22:54):

dicej opened PR #14382 from dicej:subtask-cancel-tweaks to bytecodealliance:main:

https://github.com/WebAssembly/component-model/pull/726 refined the behavior of subtask.cancel to more closely match how async-lowered calls behave, meaning the runtime must resume the cancelling thread specifically as soon as the cancellee suspends or exits.

This required some refactoring, and I believe it's a net simplification of how the runtime decides which thread to switch to and when.

• Both guest->guest calls and subtask.cancel use a new SuspendReason::YieldingToSubtask variant which replaces WaitingForGuestSubtask and means "I'm yielding specifically to the specified (via ConcurrentState::switch_item) subtask and expect to be resumed when that subtask suspends or exits."

• I've removed GuestTask::switch_item in favor of a new ConcurrentState::next_switch_item field. This addresses a case exercised by the new cancel-resumed-callback-switch.wast test where a subtask, while being cancelled, explicitly resumes a thread belonging to a different task, which then suspends, in which case we need to resume the cancelling thread. This new next_switch_item field is saved and restored as needed so that a stack of cancels and guest->guest calls can each yield to their respective subtasks and return to their respective callers/cancellers without clobbering each other.

• The new cancel-targeted-resume.wast test revealed that Wasmtime was out of compliance regarding CALLBACK_CODE_YIELD; when a task is cancelled while it is stacklessly yielding, we must promote it so the cancel event can be delivered deterministically. I've addressed this by defining a new WakeOnCancel enum type which can represent a thread which is waiting cancellably, yielding cancellably, or neither.

Since the aforementioned spec PR has not yet been merged as of this writing, I haven't updated the tests/component-model submodule yet, but I've verified locally that the new tests pass.

<!--
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 review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.md

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 23 2026 at 00:05):

:thumbs_up: alexcrichton submitted PR review.

Wasmtime GitHub notifications bot (Sep 23 2026 at 01:52):

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

Wasmtime GitHub notifications bot (Sep 23 2026 at 13:42):

dicej added PR #14382 update subtask.cancel implementation to match latest spec tweak to the merge queue.

Wasmtime GitHub notifications bot (Sep 23 2026 at 14:07):

:check: dicej merged PR #14382.

Wasmtime GitHub notifications bot (Sep 23 2026 at 14:07):

dicej removed PR #14382 update subtask.cancel implementation to match latest spec tweak from the merge queue.

Last updated: Oct 11 2026 at 02:20 UTC