Stream: git-wasmtime

Topic: wasmtime / PR #12153 allow instance to be reentered while...

Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36):

dicej requested alexcrichton for a review on PR #12153.

Wasmtime GitHub notifications bot (Dec 10 2025 at 22:36):

dicej opened PR #12153 from dicej:fix-12128 to bytecodealliance:main:

The spec says we should allow this, so now we do.

Thansk to Alex for the test case!

Fixes #12128

<!--
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 (Dec 10 2025 at 22:36):

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

Wasmtime GitHub notifications bot (Dec 10 2025 at 22:45):

alexcrichton submitted PR review:

Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically may_enter was a thing but it's no longer present in CanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handle may_enter to align with the spec)

Wasmtime GitHub notifications bot (Dec 10 2025 at 22:53):

dicej commented on PR #12153:

Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically may_enter was a thing but it's no longer present in CanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handle may_enter to align with the spec)

Search for trap_of_on_the_stack in CanonicalABI.md and the prose that follows. I agree that some renaming and/or refactoring may be due.

Wasmtime GitHub notifications bot (Dec 10 2025 at 22:53):

dicej edited a comment on PR #12153:

Code/test all look fine, but I'm trying to correlate this with the spec as well. I thought I remember that historically may_enter was a thing but it's no longer present in CanonicalABI.md. Can you clarify which point in the spec I should be looking at to double-check this? (and probably queue up some sort of rename/refactor to handle may_enter to align with the spec)

Search for trap_if_on_the_stack in CanonicalABI.md and the prose that follows. I agree that some renaming and/or refactoring may be due.

Wasmtime GitHub notifications bot (Dec 10 2025 at 23:00):

dicej commented on PR #12153:

I'm investigating the test failure; looks like dropping a subtask while it's yielding in an infinite loop will require some extra care.

Wasmtime GitHub notifications bot (Dec 11 2025 at 12:11):

alexcrichton commented on PR #12153:

Joel and I discussed this and the conclusion is that the may_enter handling in Wasmtime is outdated and no longer in sync with the spec after component-model-async refactors. Effectively we need to rebuild the reentrance check from scratch throughout Wasmtime and avoid using may_enter for the triple-purpose of: preventing reentrance, requiring post_return, and lockdown-on-trap. This'll require refactors internally to use a new component-model-async helper but will have an impact on component adapter performance as well. This all corresponds to trap_if_on_the_stack in the spec (scroll down a bit)

Wasmtime GitHub notifications bot (Dec 11 2025 at 14:53):

dicej edited a comment on PR #12153:

I'm investigating the test failure; looks like dropping a subtask while it's yielding in an infinite loop will require some extra care. EDIT: the problem is more fundamental than that, and the refactoring Alex suggested above is going to be necessary in order to fix #12128 properly.

Last updated: Dec 13 2025 at 19:03 UTC