Wasmtime GitHub notifications bot (Apr 06 2026 at 17:35): Wasmtime GitHub notifications bot (Apr 06 2026 at 17:35):dicej requested alexcrichton for a review on PR #12971.
Wasmtime GitHub notifications bot (Apr 06 2026 at 17:35):dicej opened PR #12971 from dicej:drop-waitable-set-with-stackful-waiters to bytecodealliance:main:
In
waitable_set_drop, we must check for any waiters on the set and, if there are any present, trap without removing the set. Otherwise, if one or more of those waiters are stackful (i.e.WaitMode::Fiber(_)), then removing the set will causeStoreFiber::dropto be called, which will panic since the fiber is still running.By trapping without removing the set, we defer dropping the fiber(s) until the
Storeis disposed, at which point we will dispose of them gracefully prior to dropping them.<!--
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 ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Apr 06 2026 at 17:35):dicej requested wasmtime-core-reviewers for a review on PR #12971.
Wasmtime GitHub notifications bot (Apr 06 2026 at 18:07):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Apr 06 2026 at 18:07):alexcrichton created PR review comment:
Can this be rewritten to not use
*_stackful = true?I think that should be fairly easy, just using a
callbackoption that only has anunreachableinstruction
Wasmtime GitHub notifications bot (Apr 06 2026 at 18:07):alexcrichton created PR review comment:
FWIW while comments like this can be helpful for initially reading a test case I don't think the comments about the original bug are useful long-term. Mind going through and trimming all the comments w.r.t. their explanation of thow the code previously worked? I think it's fine for this to just be a regression test case which typically just explains what it does but nothing else
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:27):dicej submitted PR review.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:27):dicej created PR review comment:
I don't believe that's possible (or at least, I can't think of a way). The problem is that the test relies on being able to re-enter the instance while another task is already running on that instance, but that's not allowed if the already-running task is stackless (i.e. callback-based).
I just verified that by adding callbacks to component
$C's two exports and got a "deadlock detected: event loop cannot make further progress" trap instead of the desired "cannot drop waitable set with waiters" trap.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:32):dicej updated PR #12971.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:35):alexcrichton has enabled auto merge for PR #12971.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:41):dicej submitted PR review.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:41):dicej created PR review comment:
For the record, I imagine we _could_ do this by enabling
component_model_threadinginsteadcomponent_model_stackfuland spawning a thread in the task, but I don't think that's any better or more understandable than what we have now.
Wasmtime GitHub notifications bot (Apr 06 2026 at 20:45):alexcrichton added PR #12971 fix panic when dropping waitable set with stackful waiter to the merge queue.
Wasmtime GitHub notifications bot (Apr 06 2026 at 21:10):alexcrichton merged PR #12971.
Wasmtime GitHub notifications bot (Apr 06 2026 at 21:10):alexcrichton removed PR #12971 fix panic when dropping waitable set with stackful waiter from the merge queue.
Last updated: Apr 13 2026 at 00:25 UTC