Changes in resources.rs

9661ca85 - Remove some more panics in `concurrent.rs` (#12874)

Mon, 30 Mar 2026 14:18:12 +0000

Remove some more panics in `concurrent.rs` (#12874)Downgrade some panics to `bail_bug!` or `?` where appropriate bypropagating `Result` in a few more locations. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

3764e757 - Refactor borrow state tracking for async tasks (#12550)

Tue, 10 Feb 2026 03:15:51 +0000

Refactor borrow state tracking for async tasks (#12550)* Refactor borrow state tracking for async tasksThis commit is a somewhat deep refactoring of how the state of`borrow` is managed for both the host and the guest with respect toasync tasks. This additionally refactors how some async task managementis done for host-called functions.The fundamental problem being tackled here is #12510. In that issue itwas discovered that the way `CallContext`, the borrow tracking mechanismin Wasmtime, is managed is incompatible with async tasks. Specificallythe previous assumption of the scope being mutated for a borrow issomewhere on the call stack is no longer true. It's possible for anasync task to be suspended, for example, and then a sibling task drops aborrow which should update the scope of the suspended task. There were anumber of other small issues I noticed here and there which this PRadditionally has tests for, all of which failed before this change andpass afterwards.The manner in which borrow state is manipulated is a pretty old part ofthe component model implementation dating back to the originalimplementation of resources. I decided to forgo any possible quick fixand have attempted to more deeply refactor and integrate async tasksinto all of this infrastructure. A list of the changes made here are:* The `CallContexts` structure, a stack of `CallContext`, was removed. Tasks now directly store a `CallContext` which is the source of truth for borrow tracking for that call, and it does not move from this location. The store `CallContexts` is now deleted in favor of updating the `Option` in the store to be an `enum` of either concurrent state or a stack. In this manner the old stack-based structure is still used sometimes, but it's impossible to reach when concurrency is enabled.* Entry to the host from guests now reliably pushes a `HostTask` into the store. Previously where a frame were always pushed into a `CallContext` a `HostTask` is pushed into the store. This is still expected to be a bit too expensive for cheap host calls, but it doesn't meaningfully change the performance profile of before.* The `resource_enter_call` and `resource_exit_call` libcalls have been removed. These are now folded into the `enter_sync_call` and `exit_sync_call` libcalls. Emission of these hooks has been updated accordingly. The concept of entering a call more generally has been removed. This is more formally known in the async world as a task starting, so the task creation is now responsible for the demarcation of entering a call. Additionally this means that the concept of exiting a call has somewhat gone away. Instead this method was renamed to `validate_scope_exit` which double-checks that a borrow-scope can be exited but doesn't actually remove the task. Task removal is deferred to preexisting mechanisms.* Management of a `GuestTask`'s previous `Option` field, for example taking/restoring and pushing/popping onto `CallContexts` is now all gone. All related code is outright deleted as the `GuestTask`'s now non-optional `CallContext` field is the source of truth.* The `ConcurrentState` structure now stores a `CurrentThread` enum instead of `Option`. This represents how the currently executing thread could be a host thread, not just a guest thread, which is required for borrow-tracking.* `HostTask` creation in `poll_and_block` and `first_poll`, the two main entrypoints of async host tasks when called by the guest, is now externalized from these functions. Instead these functions assume that the currently running thread is already a `HostTask` of some kind.* In `poll_and_block` the host's result is no longer stored in the guest task but in the host task instead.Overall this enables the `*.wast` test for #12510 to fix the originalissue. This then adds new tests to ensure that cleanup of variousconstructs happens appropriately, such as cancelling a host task shouldclean up its associated resources. Additionally synchronously calling anasync host task no longer leaks resources in a `Store` and shouldproperly clean up everything.There is still more work to do in this area (e.g. #12544) but that'sgoing to be deferred to a future PR at this point.Closes #12510prtest:full* Review comments/CI fixes List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

cb97ae85 - allow recursive Wasm invocation from concurrent host functions (#12152)

Thu, 11 Dec 2025 23:03:58 +0000

allow recursive Wasm invocation from concurrent host functions (#12152)* allow recursive Wasm invocation from concurrent host functionsThe core changes here are:- remove an unnecessary assertion from `concurrent::prepare_call`- track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis - both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally uniqueWhile discussing the above with Alex, we realized the use of a `HashMap` totrack per-instance states was both pessimal and unnecessary. Consequently, I'vefolded that state into `ComponentInstance::instance_handle_tables`, renaming itto `instance_states`. That involved a fair amount of code churn, but doesn'tchange behavior except as described in the second bullet point above.Thanks to Alex for the test case!Fixes #12098Co-authored-by: Alex Crichton Signed-off-by: Joel Dice * use new `RuntimeInstance` type instead of tuplesSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

8fbe4c2c - Fix some panics compiling components and resources (#11798)

Mon, 06 Oct 2025 22:36:55 +0000

Fix some panics compiling components and resources (#11798)In working on bytecodealliance/wasm-tools#2335 I found that there's afew test cases in wasm-tools which Wasmtime was panicking to compile.The issues were all related to resource types and how information wasn'tregistered ahead of time before it was translated from wasmparser'srepresentation to Wasmtime's representation. The high-level cause forthis had to do with how component and instance types are handled, asopposed to concrete components or instances themselves. This waseffectively a hole in Wasmtime's translation process for componentswhich has never been filled out since the original implementation ofresources. The reason that this never came up before is:* Most components don't currently import or export a component itself.* Most components don't currently import or export component or instance types (as opposed to values).One of these was required to trigger this issue. The solutionimplemented in this commit is to plumb the concept of an "abstractresource" which is part of a type but not actually ever used at runtimeexcept for type equality during type reflection. This is expected tohave little-to-no impact on real-world components given that thesesituations are rarely occurring. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

e8189549 - use a single table per instance for resources, waitables, etc. (#11374)

Tue, 12 Aug 2025 20:34:35 +0000

use a single table per instance for resources, waitables, etc. (#11374)* use a single table per instance for resources, waitables, etc.Per https://github.com/WebAssembly/component-model/pull/513, the spec now putsresources, waitables, waitable sets, subtasks, and error contexts in the sametable per instance. This updates the implementation to match.- Combine the `ResourceTable` and `StateTable` data structures into a single `HandleTable` structure- Rename `ComponentInstance::instance_resource_tables` to `instance_handle_tables`- Remove `ConcurrentState::waitable_tables` and `error_context_tables` in favor of the above- Move various associated functions from `ConcurrentState` to `ComponentInstance` so they can access `instance_resource_tables`While I was doing table-related things, I also updated `concurrent::Table::new`to reserve the zero handle to mean "invalid". This won't affect what the guestsees in any way, but it allows us to use `TableId::new(0)` to invalidatehost-owned handles in e.g. `{Stream,Future}{Reader,Writer}::close`.Fixes #11189Signed-off-by: Joel Dice Re-internalize `ResourceKind` to `mod handle_table`Remove `ResourceKind`Start flattening the representation of `Slot`Internalize `get_mut_handle_by_index`Internalize implementation details such as the representation of slotsto and make methods a bit more targeted in their functionality.Internalize more details of `HandleTable`Don't expose `HandleKind` and of per-function methods for operating onthe various kinds of handles that reside in the table.Flatten the representation of `Slot`There's still some more work to do for host/guest resource handles, butthis helps realize the goal of the previous refactorings in themeantime.* stop using `HandleTable::reps_to_indexes` when delivering eventsPer review feedback, we'd like to get rid of `HandleTable::reps_to_indexes`entirely. This commit doesn't go quite that far, but now we only use it for`error-context` handles. For waitables, which can only be referenced by at mostone guest at a time, we now store the guest handle in `WaitableCommon::handle`and retrieve it from there when delivering an event for that waitable.For `error-context` handles, the spec requirement that we always lower the samehandle for the same `error-context`, combined with the fact that an`error-context` may be referenced by more than one component instance at a time,means we still need some general way to convert a host rep plus component indexinto a handle. Going forward, we could consider either removing that "samehandle" requirement from the spec or consider an alternative implementation(e.g. storing a `HashMap` in the `ErrorContext`host state for keeping track of the handles for each referencing instance.Signed-off-by: Joel Dice * remove `HandleTable::reps_to_indexes`Turns out the spec no longer requires that guests receive the same handle for agiven `error-context` as the one they already have, so we no longer need thisfield -- nor do we need to maintain a per-component-instance reference count.Signed-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

b221fca7 - update `component-model-async` plumbing (#11123)

Thu, 03 Jul 2025 22:03:59 +0000

update `component-model-async` plumbing (#11123)* [DO NOT MERGE] update `component-model-async` plumbingThis pulls in the latest Component Model async ABI code from the`wasip3-prototyping` repo, including various API refactors and spec updates.This includes all the changes to the `wasmtime` crate from `wasip3-prototyping`_except_ that the `concurrent` submodule and child submodules contain onlynon-functional stubs. For that reason, and the fact thate.g. `Func::call_async` is now implemented in terms of `Func::call_concurrent`,most of the component model tests are failing. This commit is not meant to bemerged as-is; a follow-up commit (to be PR'd separately) will contain the real`concurrent` implementation, at which point the tests will pass again. I'msplitting these into separate PRs to make review easier.Signed-off-by: Joel Dice * Undo wit-bindgen changesNo longer necessary after other refactors* Move back to crates.io-based wit-bindgen* Undo upgrade of http-body-util(deferred for future PR)* Add back in arbitrary use of asyncLooks like it may have been lost by accident* Make imports more conventional for Wasmtime* Some minor changes* Privatize a component field* Cut down a bit on #[cfg]* Undo a no-longer-necessary `pub`* add doc comments for `{Future,Stream,ErrorContext}Any`Signed-off-by: Joel Dice * rename `concurrent` stub module to `concurrent_disabled`...and avoid panicking in the stubs.Signed-off-by: Joel Dice * fix test regressionSigned-off-by: Joel Dice * revert `call_async` and `post_return_impl` changesThese will need to wait until the `component-model-async` feature is fullyimplemented.Signed-off-by: Joel Dice * remove unused structSigned-off-by: Joel Dice * add `Options::callback` fieldThis isn't used yet, but will be used when the real `component-model-async`implementation is merged.Signed-off-by: Joel Dice * Remove no-longer-needed feature* Trim reexports from WasmtimeSome of these are no longer needed or can be avoided with small changes.Some deps are likely needed in the next commit but they'll be best addedthere.* Update test expectations* More trimming of Cargo.toml* Defer `*Buffer` traits to next PRNot needed for this PR I believe.* Use conventional Wasmtime imports + remove dummy_waker* Reduce duplication in `*_disabled`* Remove some unncessary bounds* Remove some `for<'a>` bounds where unnecessary* Remove another bound* Defer more functions to the next PR`drop_fibers` is different in the next PR, so defer it to then.* Remove some reexports no longer necessaryBindings generation changed awhile back so these aren't needed, deferthe implementations to the next PR.* Remove unnecessary dropThis was already moved to `run_manual_drop_routines`* Defer a `pub(crate)` to a future PR* Expand comments in traphandlers* Defer some types to the next PR* Update linker documentation* Add `Send`/`Sync` bounds to `ComponentType`This commit is extracted from from review of #11123 and #11127. Whilenot literally present in those PRs it's my own personal conclusion thatit's best to just go ahead and add these bounds at the "base" of thecomponent trait hierarchy. The current implementation in #11123 addsbounds in many locations and this would remove the need to add boundseverywhere and instead have everything inherited through the `Lift` and`Lower` traits.This raises the question of: why? The main conclusion that I've reachedleading to this change is that Wasmtime currently will store `R`, areturn value, on the stack during the lowering process back into linearmemory. This might involve allocation, however, meaning that wasm can beinvoked and a context switch could happen. For Wasmtime's `unsafe impl`of `Send` and `Sync` on fibers to be sound it requires that thisstack-local variable is also `Send` and `Sync` as it's an entirelyuser-provided type. Thus I've concluded that for results it's alwaysrequired for these to be both `Send` and `Sync` (or at the very least,`Send`).Given that I've gone ahead and updated to require both `Send` and `Sync`for both params and results. This is not expected to actually have anyimpact in practice since all primitives are already `Send`/`Sync` (minus`Rc` impls all removed here) and all `bindgen!`-generated types arecompositions of `Send`/`Sync` primitives meaning that they're also`Send` and `Sync`.* Remove some now-unnecessary bounds* Fix build after #11160* Remove some now-unnecessary duplicate bounds* Uncomment test that now works* Undo accidental doc wrap* Clarify comment on `Value` typesDon't leave `TODO` in public-facing documentation ideally* Actually resolve the conflict (forgot to commit)* Avoid returning boxed futures in APIs* Defer making constructors more public to a future PR* Make a method name more conventional* Refactor `linear_lift_into_from_memory`* Drop the `max_count` parameter in favor of slicing the `WasmList` itself. Avoids situations such as what happens if `max_count` is larger than the length of the list.* Don't have the default implementation collect to a vector and then push all that onto a different vector. Instead push each item individually through `extend`.* De-indent a block of code added* Remove unsafety from `prepare_call`Mostly move the parameters themselves to the closure to avoid rawpointers/drop/etc.This will have the consequence of in the future `call_async` is going tonow require `Params: 'static` but that seems more-or-less inevitable atthis point.* Go back to returning box, alas.* Apply same treatment to lift functionMake it a closure and reduce some levels of indirection of the variousfunctions in play.* Refactor `lower_params` to require less context.Relax the bounds on the closure specified since it's immediately calledand then additionally take out parameters/captures that the closure cancarry itself.* Don't pass extraneous `Instance` parameterThis can now be inferred from `Func`.* Clean up some SAFETY comments* Generalize the signature of `lift_results`* Move `lift_results` function to `Func`Also rename the lift/lower helpers to `with_{lift,lower}_context`* Remove parameter from `with_lift_context`Like `with_lower_context` this is fine to capture in the closure passedin.* Simplify the dynamic lifting logicDon't call `with_lift_context` in two locations, only call it once witha dynamic parameter.* Refactor away the `Func::lift_results_sync` helper* Use `with_lift_context` in `call_raw`* Simplify a call to `Func::call_unchecked_raw`* Ungate `with_lift_context` to fix non-cm-async build* Fix compile (bad cherry-pick conflict resolution)* Use `with_lower_context` in `call_raw`Trying to unify the async/concurrent paths as much as possible.* Move params out of `call_raw`Let closures capture the params, no need to thread it through as anunnecessary argument.* Clean up unsafety in `Func::call_raw`* Accurately mark `call_raw` itself as `unsafe`, then document why callers should be safe.* Don't have one large `unsafe` block in `call_raw`, instead split it up with separate safety comments.* Move a one-off type definition closer to its use* Avoid intermediate allocations in dynamic calls* Simplify a future-return site* Deduplicate checking parameter count* Simplify a future invocation with `?`* Simplify a variable declaration* Simplify some function signatures* Remove outdated safety comment* Refactor to not require `Params: 'static` on `call_async`* Remove no-longer-necessary SAFETY comment* Fix typos* Add a fast-path with no `Box` for sync host functionsSpeeds up host calls by ~20% and puts them back on parity with thebeforehand numbers Wasmtime has.* Synchronize signatures of async/concurrent dynamic callsUse slices for both instead of vecs for one and slices for the other.Required some slight rejiggering. Apparently one can solve a closureproblem with another closure, then one surely has no more closureproblems.* Fix non-cm-async build---------Signed-off-by: Joel Dice Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

90ac295e - Update Wasmtime to the 2024 Rust Edition (#10806)

Mon, 19 May 2025 16:40:55 +0000

Update Wasmtime to the 2024 Rust Edition (#10806)* Update Wasmtime to the 2024 Rust EditionNow that our MSRV supports the 2024 edition it's possible to make thisswitch. This commit moves Wasmtime to the 2024 Edition to keepup-to-date with Rust idioms and access many of the edition featuresexclusive to the 2024 edition.prtest:full* Reformat with the 2024 edition List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

28e26fdf - Collapse resource tables to be per-instance, not per-resource (#10701)

Wed, 30 Apr 2025 22:09:45 +0000

Collapse resource tables to be per-instance, not per-resource (#10701)This commit is an update to how Wasmtime represents and processesresource handles for components. The upstream specification changed inWebAssembly/component-model#427 and while it's been awhile since thatchange this is Wasmtime catching up to that change. It's expected thatthese paths are going to get stressed more with component model asyncand more kinds of handles so this additionally refactors things to leavesort 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 couldhave overlapping indices and now they're going to all have disjointindices since they're all in the same index space. It's expected thatthis is will have a minimal, if any, impact on component guests as intheory they're all mostly treating handles as opaque indexes todayanyway. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

1512a954 - Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)

Fri, 14 Jun 2024 15:24:12 +0000

Add `anyhow` stuff to our internal `wasmtime` crate prelude (#8804)* Add `anyhow` stuff to our internal `wasmtime` crate preludeWe use it basically everywhere and it is annoying to have to import.I also did an audit of existing `use` statements and removed the now-redundantones and replaced one-off imports with usage of the prelude, so that the preludeis available by default in more places.* Fix `cargo doc` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

0e9121da - Fix some typos (#8641)

Thu, 16 May 2024 23:21:22 +0000

Fix some typos (#8641)* occurred* winch typos* tests typos* cli typos* fuzz typos* examples typos* docs typos* crates/wasmtime typos* crates/environ typos* crates/cranelift typos* crates/test-programs typos* crates/c-api typos* crates/cache typos* crates other typos* cranelift/codegen/src/isa typos* cranelift/codegen/src other typos* cranelift/codegen other typos* cranelift other typos* ci js typo* .github workflows typo* RELEASES typo* Fix clang-format documentation line---------Co-authored-by: Andrew Brown List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

81a89169 - Add support for `#![no_std]` to the `wasmtime` crate (#8533)

Sat, 04 May 2024 22:02:26 +0000

Add support for `#![no_std]` to the `wasmtime` crate (#8533)* Always fall back to custom platform for WasmtimeThis commit updates Wasmtime's platform support to no longer require anopt-in `RUSTFLAGS` `--cfg` flag to be specified. With `no_std` becomingofficially supported this should provide a better onboarding experiencewhere the fallback custom platform is used. This will cause linkererrors if the symbols aren't implemented and searching/googling shouldlead back to our docs/repo (eventually, hopefully).* Change Wasmtime's TLS state to a single pointerThis commit updates the management of TLS to rely on just a singlepointer rather than a pair of a pointer and a `bool`. Additionallymanagement of the TLS state is pushed into platform-specific modules toenable different means of managing it, namely the "custom" platform nowhas a C function required to implement TLS state for Wasmtime.* Delay conversion to `Instant` in atomic intrinsicsThe `Duration` type is available in `no_std` but the `Instant` type isnot. The intention is to only support the `threads` proposal if `std` isactive but to assist with this split push the `Duration` further intoWasmtime to avoid using a type that can't be mentioned in `no_std`.* Gate more parts of Wasmtime on the `profiling` featureMove `serde_json` to an optional dependency and gate the guest profilerentirely on the `profiling` feature.* Refactor conversion to `anyhow::Error` in `wasmtime-environ`Have a dedicated trait for consuming `self` in addition to a`Result`-friendly trait.* Gate `gimli` in Wasmtime on `addr2line`Cut down the dependency list if `addr2line` isn't enabled since thenthe dependency is not used. While here additionally lift the versionrequirement for `addr2line` up to the workspace level.* Update `bindgen!` to have `no_std`-compatible outputPull most types from Wasmtime's `__internal` module as the source oftruth.* Use an `Option` for `gc_store` instead of `OnceCell`No need for synchronization here when mutability is already available inthe necessary contexts.* Enable embedder-defined host feature detection* Add `#![no_std]` support to the `wasmtime` crateThis commit enables compiling the `runtime`, `gc`, and `component-model`features of the `wasmtime` crate on targets that do not have `std`. Thistags the crate as `#![no_std]` and then updates everything internally toimport from `core` or `alloc` and adapt for the various idioms. Thisended up requiring some relatively extensive changes, but nothing tootoo bad in the grand scheme of things.* Require `std` for the perfmap profiling agentprtest:full* Fix build on wasm* Fix windows build* Remove unused import* Fix Windows/Unix build without `std` feature* Fix some doc links* Remove unused import* Fix build of wasi-common in isolation* Fix no_std build on macos* Re-fix build* Fix standalone build of wasmtime-cli-flags* Resolve a merge conflict* Review comments* Remove unused import List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs

72004aad - Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)

Tue, 30 Apr 2024 18:52:45 +0000

Turn the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module (#8501)* Expose `wasmtime-runtime` as `crate::runtime::vm` internally for the `wasmtime` crate* Rewrite uses of `wasmtime_runtime` to `crate::runtime::vm`* Remove dep on `wasmtime-runtime` from `wasmtime-cli`* Move the `wasmtime-runtime` crate into the `wasmtime::runtime::vm` module* Update labeler for merged crates* Fix `publish verify`prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/resources.rs