Put resources handles into a single table per component instance, instead of per-resource-type-per-instance #427
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…, instead of per-resource-type-per-instance Resolves #395
Member
|
It helps that this isn't exposed in the public interface of components, so if in the future we decide we want different behavior, we could have options. |
sunfishcode
approved these changes
Dec 6, 2024
alexcrichton
approved these changes
Dec 6, 2024
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Apr 30, 2025
This commit is an update to how Wasmtime represents and processes resource handles for components. The upstream specification changed in WebAssembly/component-model#427 and while it's been awhile since that change this is Wasmtime catching up to that change. It's expected that these paths are going to get stressed more with component model async and more kinds of handles so this additionally refactors things to leave sort of "holes" where async resources are going to go. This notably will result in different behavior for guest programs. Previously if there were two resources imported into a guest they could have overlapping indices and now they're going to all have disjoint indices since they're all in the same index space. It's expected that this is will have a minimal, if any, impact on component guests as in theory they're all mostly treating handles as opaque indexes today anyway.
github-merge-queue bot
pushed a commit
to bytecodealliance/wasmtime
that referenced
this pull request
Apr 30, 2025
This commit is an update to how Wasmtime represents and processes resource handles for components. The upstream specification changed in WebAssembly/component-model#427 and while it's been awhile since that change this is Wasmtime catching up to that change. It's expected that these paths are going to get stressed more with component model async and more kinds of handles so this additionally refactors things to leave sort of "holes" where async resources are going to go. This notably will result in different behavior for guest programs. Previously if there were two resources imported into a guest they could have overlapping indices and now they're going to all have disjoint indices since they're all in the same index space. It's expected that this is will have a minimal, if any, impact on component guests as in theory they're all mostly treating handles as opaque indexes today anyway.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As discussed in #395. This simplifies the implementation (avoiding likely subtle incompatibilities) and helps developers catch and understand bugs while maintaining determinism. In context, the overhead of the extra branch should be negligible.