dicej requested alexcrichton for a review on PR #14416.
dicej opened PR #14416 from dicej:task-group-hook to bytecodealliance:main:
This addresses #14247 and roughly resembles the API sketch Alex posted as a comment on that issue.
Although the Component Model has no notion of a "task group", we define one here in order to enable embedders to associate guest->host calls with corresponding host->guest calls in a predictable way. See the doc comments on
TaskGroupHookfor details on what it means for a task to be part of a task group and what notifications a hook will receive for a given group.Note that, unlike with
CallHookHandler, the functions inTaskGroupHookdo not have aStoreContextMut<T>parameter. Supporting such a parameter is technically possible, but would require converting a _lot_ of functions so that they accept&mut dyn VMStoreparameters instead of&mut StoreOpaqueparameters, including parts of the public API. This is something we can revisit later, if desired. Meanwhile, types implementingTaskGroupHookmay need to use e.g.Arcto share state with theTinStore<T>.This feature supersedes
StoreContextMut::async_call_stack, which I've removed given that it is prone to use-after-free of a table slot as described in the aforementioned issue.Fixes #14247
<!--
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.htmlPlease review the Bytecode Alliance's AI tool usage policy at
https://github.com/bytecodealliance/governance/blob/main/AI_TOOL_POLICY.mdPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
dicej requested wasmtime-core-reviewers for a review on PR #14416.
dicej requested wasmtime-default-reviewers for a review on PR #14416.
github-actions[bot] added the label wasmtime:api on PR #14416.
:speech_balloon: lann created PR review comment:
I guess if you count the part about "semantic tail-calls" this really is just about the root task lifetime. Apart from maybe mentioning that here I still think "task group" makes sense, being analogous to a posix process group.
:memo: lann submitted PR review.
:memo: lann submitted PR review.
:speech_balloon: lann created PR review comment:
What happens when these return
Err?
:speech_balloon: lann edited PR review comment.
:memo: lann submitted PR review.
:speech_balloon: lann created PR review comment:
If this returns an error will it leak the
TaskGroup? Or will the wholeConcurrentStateget dropped immediately anyway?
:memo: alexcrichton submitted PR review:
Could this perhaps be something where a
task_group_hook.rssubmodule could be made to help split out code and reduce the#[cfg]traffic inconcurrent.rs? (also in the spirit of keeping the file a bit smaller...)Also, would it make sense to revert other work from #13510 such as the
FuncCallConcurrentabstraction? (as that's sort of no longer relevant)
:speech_balloon: alexcrichton created PR review comment:
In addition to having the method here, can the method also be on
StoreContextMut?
:speech_balloon: alexcrichton created PR review comment:
Would it be possible to integrate this into
GuestTask::newand perhapsHostTask::new?I'm a bit wary to sprinkle incref/decref throughout the code in various locations because it feels like inevitably we'll forget to put one somewhere. By handling it once on construction and once on destruction however that feels more natural to me.
:speech_balloon: alexcrichton created PR review comment:
I think ideally this location would be the "one single location" that the decrement happens -- would it be possible to shuffle things around such that that's the case?
:speech_balloon: alexcrichton created PR review comment:
Could this perhaps get hooked into the deferred-host infrastructure? For example only incref'd when the host task is actually created?
:memo: lann submitted PR review.
:speech_balloon: lann created PR review comment:
It might be a little weird to attach the hook in the middle of task exection? :thinking:
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
Yes, that will trap and poison the store. This was a good reminder to review the various ways a host can call into a component, cause these hooks to run, and return an error, in which case we need to poison the store even if the error happened without any guest code on the stack. I'll push an update which covers the cases I found that weren't already covered.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I'll push an update which ensures that
TaskGroupHook::handle_finishis called on anyTaskGroups still in the table when the store is dropped.
:speech_balloon: dicej edited PR review comment.
:speech_balloon: dicej edited PR review comment.
dicej requested pchickey for a review on PR #14416.
dicej updated PR #14416.
dicej requested wasmtime-wasi-reviewers for a review on PR #14416.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I've added a footnote referencing the semantic tail-calls blurb.
:speech_balloon: dicej created PR review comment:
I've added a paragraph to the doc comment describing what happens when these functions return
Err, and more generally what events will be delivered if the store traps for any reason.
:memo: dicej submitted PR review.
dicej updated PR #14416.
dicej updated PR #14416.
dicej updated PR #14416.
I believe I've addressed all the feedback so far.
:memo: alexcrichton submitted PR review:
A few minor things, mostly I think a
*_disabled.rsfile would work well here, but otherwise lgtm
:speech_balloon: alexcrichton created PR review comment:
A #[cfg]'d method parameter in a publi-facing trait can sort of wreak havoc with dependencies -- could this be
Option<TaskGroupId>?
:speech_balloon: alexcrichton created PR review comment:
Can you add inline docs to this feature here?
:speech_balloon: alexcrichton created PR review comment:
To clarify as well, I don't think that this file should have zero
#[cfg]in it, but I think it could still be reduced quite a bit by having enabled/disabled files, and that I think is beneficial to have a file that contains 99%+ of the implementation as opposed to as-is where you've got to cross-reference a few file simultaneously to find the body of the implementation.
:speech_balloon: alexcrichton created PR review comment:
Could this be defined as a noop for task-group-hook-disabled to avoid the #[cfg] here?
:speech_balloon: alexcrichton created PR review comment:
FWIW this file still has quite a lot of
#[cfg]which IMO defeats most of the purpose of outlining it intotask_group_hook.rsas the goal is to generally have everything in one location with little #[cfg] necessary. That being said I might recommend some changes here to assist with that and reduce the #[cfg] this file. Notably atask_group_hook_disabled.rswould be a location to have stubs that do nothing, and that would enable this file to ideally have far less#[cfg]to assume that task group management should always be done. If the feature is disabled the functions would be noops, but when enabled it'd route intotask_group_hooks.rs.
dicej updated PR #14416.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I just pushed an update which makes
TaskGroupIda unit type when thetask-group-hookfeature is disabled, so now this parameter is present unconditionally, with noOption<_>needed.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I just pushed an update; please let me know what you think.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
Err, hold on, let me address the CI issues first.
dicej updated PR #14416.
dicej updated PR #14416.
dicej updated PR #14416.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
Ok, really this time.
:thumbs_up: alexcrichton submitted PR review:
Just some minor nits, but lgtm :+1:
:speech_balloon: alexcrichton created PR review comment:
For this can you add
{ _priv: () }to ensure that this isn't publicly-visible/constructible as an empty struct?
:speech_balloon: alexcrichton created PR review comment:
Bikeshed on this a bit:
hook_switch_threads? (switch_threads feels a bit too powerful/generic for what it's doing)
:speech_balloon: alexcrichton created PR review comment:
Unnecessary cfg now I think?
:speech_balloon: alexcrichton created PR review comment:
Could this be moved down to
mod task_group_hook_disabled? This sort of renaming stylistically typically happens near themoddeclaration vs imports from other crates/modules.
:speech_balloon: alexcrichton created PR review comment:
This might be able to
pub use task_group_hook::*to avoid individually listing each name
:speech_balloon: alexcrichton created PR review comment:
indentation a bit off
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
True, but I tend to avoid wildcard imports; they make it harder for the reader to determine where a given symbol is defined.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I know, but
rustfmtinsists :shrug:
dicej updated PR #14416.
:memo: dicej submitted PR review.
:speech_balloon: dicej created PR review comment:
I changed it to
handle_thread_switch.
dicej has enabled auto merge for PR #14416.
dicej added PR #14416 add (off-by-default) task-group-hook feature to the merge queue.
github-merge-queue[bot] removed PR #14416 add (off-by-default) task-group-hook feature from the merge queue.
dicej updated PR #14416.
dicej has enabled auto merge for PR #14416.
dicej added PR #14416 add (off-by-default) task-group-hook feature to the merge queue.
:check: dicej merged PR #14416.
dicej removed PR #14416 add (off-by-default) task-group-hook feature from the merge queue.
Last updated: Oct 11 2026 at 04:10 UTC