alexcrichton opened PR #14158 from alexcrichton:resource-context-in-drop to bytecodealliance:main:
This commit updates the translation of resource destructors in the component model to unconditionally setup a sync task as the spec specifies. This resolves an issue where context slots were leaking across boundaries when a component destroyed its own resource.
While here this updates the translation to use the inline fast path that is present in sync-to-sync adapters by juggling some code to make it sharable by the two locations.
<!--
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
-->
alexcrichton requested fitzgen for a review on PR #14158.
alexcrichton requested wasmtime-compiler-reviewers for a review on PR #14158.
alexcrichton requested wasmtime-core-reviewers for a review on PR #14158.
:speech_balloon: fitzgen created PR review comment:
Test coverage of the symmetric trapping cases? Probably worth exercising trapping before and after forcing the lazy thread.
:thumbs_up: fitzgen submitted PR review:
r=me with nitpick below addressed
Also, do you want to have a disas test as well?
:memo: alexcrichton submitted PR review.
:speech_balloon: alexcrichton created PR review comment:
Could you expand on the trapping cases you're thinking of? The original intention for these tests was testing
context.{get,set}in the context of resource destructors as opposed to trapping (where before it was just bad context set)
:speech_balloon: fitzgen created PR review comment:
I was thinking when the resource destructor itself traps, and then we do something else with the store to check that the thread context is cleaned up correctly for those new calls.
:memo: fitzgen submitted PR review.
:memo: alexcrichton submitted PR review.
:speech_balloon: alexcrichton created PR review comment:
Oh we don't clean up anything on traps, not only here but in tons of places. That generally works out though because once an instance traps it can't ever be used again, so there can't be a test anyway for reusing a component after a trap.
:memo: fitzgen submitted PR review.
:speech_balloon: fitzgen created PR review comment:
We do clean up the
VMDeferredThreadstuff, which is what I was getting at: checking that if the resource destructor traps and then we later re-enter the store, we don't get staleVMDeferredThreadstuff.
alexcrichton updated PR #14158.
:speech_balloon: alexcrichton created PR review comment:
Ah ok I see yeah, ok added some tests!
:memo: alexcrichton submitted PR review.
alexcrichton commented on PR #14158:
I'm going to skip the disas test for now since the main purpose here is runtime functionality
alexcrichton has enabled auto merge for PR #14158.
alexcrichton added PR #14158 Unconditionally setup tasks for resource destructors to the merge queue.
:check: alexcrichton merged PR #14158.
alexcrichton removed PR #14158 Unconditionally setup tasks for resource destructors from the merge queue.
Last updated: Aug 30 2026 at 09:07 UTC