Changes in handle_table.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/handle_table.rs

57f899c4 - Move threads to their own index space in components (#12516)

Wed, 04 Feb 2026 19:42:35 +0000

Move threads to their own index space in components (#12516)* Move threads to their own index space in componentsThis accounts for WebAssembly/component-model#600 and mostly updatesvarious test expectations to match this.Closes #11954* Fix conditional compiles List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/handle_table.rs

96e19700 - Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)

Wed, 07 Jan 2026 17:08:11 +0000

Migrate the `wasmtime` crate to `wasmtime_environ::error::*` (#12231)* Migrate the `wasmtime` crate to `wasmtime_environ::error::*`Instead of `anyhow::Error`.This commit re-exports the `wasmtime_environ::error` as the `wasmtime::error`module, updates the prelude to include these new error-handling types, redirectsour top-level `wasmtime::{Error, Result}` re-exports to re-export`wasmtime::error::{Error, Result}`, and updates various use sites that weredirectly using `anyhow` to use the new `wasmtime` versions.This process also required updating the component macro and wit-bindgen macro touse the new error types instead of `anyhow`.Part of https://github.com/bytecodealliance/wasmtime/issues/12069* Replace wasmtime::error::Thing with wasmtime::Thing where it makes sense* cargo fmt* Move `crate::error::Thing` to `crate::Thing` where it makes sense List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/handle_table.rs

e06fbf70 - Cooperative Multithreading (#11751)

Mon, 27 Oct 2025 21:39:35 +0000

Cooperative Multithreading (#11751)* Initial work* Almost compiling* Partially working* Cleanup* Fix merge* Cancellation and suspension refactoring* Remove printlns* Test with several threads* More testing* Cancellation* Fix cancellation for explicit suspends* Finish cancellation test* Store threads in the instance table* Deletion almost there* Tests all pass* Tighten up task deletion* Set thread state correctly* Store pairs of thread and task ids* Remove lift abi members* Cleanup unnecessary change* More cleanup* Cleanup* Revert cargo changes* Revert cargo changes* Comments* Comments on test* Update comments* Update comments* Add space that was removed in an earlier commit* Cleanup* Delete threads from the instance table* Revert cargo file* Remove dead code* Clippy changes* Clippy* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Revert unnecessary changes* Review comments* Review feedback* Make thread IDs per-component-instance* Fix config* Tighten up completion* Clippy* Trigger full PR test* Move funcref table reading* Remove unused import* Formatting* Rename RemoveOnDrop* Review feedback* Review feedback* Move start thread closure* Review feedback* Review feedback* Correct feature for import* Review feedback* Disable failing tests* Enable fixed tests* Review feedback* Readd tests* Ignore task deletion test with Miri List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/vm/component/handle_table.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/handle_table.rs