Skip to content

Conversation

@lukewagner
Copy link
Member

As described in a new blurb in this PR (in the Thread State section in CanonicalABI.md), the main motivation this change is to help an optimization engine cheaply lazily allocate thread elements, saving the real initialization until a real stack-switching operation occurs. Having threads in the same handle table as everything else would otherwise thwart this optimization since unrelated resource/waitable handle allocations would shift the indices around. This also has the pleasant effect of reverting what was otherwise a semantic change from when cooperative threads were added: an export's implicit thread is allocated a thread index which observably shifts indices (thereby causing annoyance when enabling/disabling the coop-threads feature changes index allocation).

dicej added a commit to dicej/component-model that referenced this pull request Jan 22, 2026
While rebasing bytecodealliance/wasmtime#12379 onto
Wasmtime's `main` branch, I found I needed to tweak the expected resource handle
values and trap messages due to subtle changes to when Wasmtime allocates a
thread handle.  Once WebAssembly#600
lands and is implemented in Wasmtime, we should be able to clean all this up
once and for all; for now we just muddle along.
lukewagner pushed a commit that referenced this pull request Jan 22, 2026
While rebasing bytecodealliance/wasmtime#12379 onto
Wasmtime's `main` branch, I found I needed to tweak the expected resource handle
values and trap messages due to subtle changes to when Wasmtime allocates a
thread handle.  Once #600
lands and is implemented in Wasmtime, we should be able to clean all this up
once and for all; for now we just muddle along.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants