Changes in func.rs

58877f2f - Fix the current guest task when calling `realloc` (#12718)

Wed, 04 Mar 2026 21:14:33 +0000

Fix the current guest task when calling `realloc` (#12718)* Fix the current guest task when calling `realloc`This commit fixes some fallout from #12550 where after that PR thecurrent task registered when a guest's `realloc` was called wasincorrect. This additionally fixes issues where guest-to-guesttrampolines also had the wrong task registered when `realloc` was beingcalled. Finally this adjusts a few locations that "no borrows should beactive" traps happen to ensure that it happens around the time of when atask returns rather than after the lowering of its values happens.* Fix non-async build List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

da093747 - Relax panics in async/futures to traps/errors (#12688)

Mon, 02 Mar 2026 21:26:40 +0000

Relax panics in async/futures to traps/errors (#12688)* Relax panics in async/futures to traps/errorsThis commit is an admittance that I don't believe we're going to getto a point where we are confident enough in the fuzzing ofcomponent-model-async such that we could confidently say we'reexercising the vast majority of possible panics. Development ofcomponent-model-async has shown a steady trickle of panics over thecourse of the development of the feature, and this trend has beenpersistent over time as well.An attempt was made in #12119 to add a fuzzer dedicated to async eventsbut that didn't actually find anything in development and it has misseda number of panics present before and discovered after its introduction.Overall I do not know how to improve the fuzzer to the point that itwould find pretty much all of the existing async-related panics overtime.To help address this concern of the `concurrent.rs` implementation thiscommit goes through and replaces things like `unwrap()`, `assert!`,`panic!`, and `unreachable!` with an error-producing form. The benefitof this is that a bug in the implementation is less likely to result ina panic and instead just results in a non-spec-compliant trap. Thedownside of doing this though is that it can become unclear what errorsare "first class traps", or expected to be guest reachable, and whichare expected to be bugs in Wasmtime. To help address this I've performeda few refactorings here as well.* Some traps previously present as error strings are now promoted to using `Trap::Foo` instead. This has some refactoring of the Rust/C side as well to make it easier to define new variants. Tests were additionally added for any trap messages that weren't previously tested as being reachable.* A new `bail_bug!` macro was added (internally) for Wasmtime. This is coupled with a concrete `WasmtimeBug` error type (exported as `wasmtime::WasmtimeBug`). The intention is that `bail!` continues to be "here's a string and I'm a bit too lazy to make a concrete error" while `bail_bug!` indicates "this is a bug in wasmtime please report this if you see it".The rough vision is that if an error condition is reached, and the systemis not broken in such a way that panicking is required, then `bail_bug!`can be used to indicate a bug in Wasmtime as opposed to panicking. Thisreduces the real-world impact of hitting these scenarios by downgrading aCVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not allpanics are able to be transitioned to this as some are load bearing froma safety perspective or similar (or indicate something equally broken),but the vast majority of cases are suitable for "return a trap, lockdown the store, and let destructors take care of everything else".This change additionally has resulted in API changes for `FutureReader`and `StreamReader`. For example creation of these types now returns a`Result` for when the `ResourceTable` is full, for example, instead ofpanicking.* Fix CI build* Translate `WasmtimeBug` to panics in debug mode* Review comments* Refactor some stream methods for fewer panics List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

1e0b0b46 - Remove subtask reparenting (#12570)

Mon, 23 Feb 2026 21:00:21 +0000

Remove subtask reparenting (#12570)This commit updates the implementation of component-model-asyncprimitives to remove the manual subtask reparenting process. This isrequired to fix #12544 at a semantic level because a subtask isn't everactually reparented, even if its parent exits. The first part of thischange is to remove the `GuestTask::subtasks` field and all relevantmanipulations of it.This field, however, powered the `TaskExit` abstraction returned from`call_concurrent`. This commit then subsequently deletes `TaskExit` andall related infrastructure as it's no longer directly applicable as-is.The rest of this change is then updating tests/bindings/etc to accountfor these two changes.The main semantic changes related to tests are:* `wasmtime run`, with and without `--invoke`, no longer waits for all subtasks. This instead only waits for the main task returning before exiting. Whether or not this is the correct behavior is under discussion in WebAssembly/component-model#608* `wasmtime serve` has been updated to keep the store alive at least until the response body has been fully transmitted. This is also part of WebAssembly/component-model#608.* Some `component-async-tests`-related tests were updated to either avoid blocking the store as it wasn't needed or yield enough times to ensure that the test passes.Closes #12544prtest:full List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.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/component/func.rs

1d8827f3 - Delete an unused field in `GuestTask` (#12545)

Mon, 09 Feb 2026 20:27:35 +0000

Delete an unused field in `GuestTask` (#12545)Looks like there are no more users of this field, so no need to persistit. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

98499653 - Move `ResourceTables` constructors to `StoreOpaque` (#12546)

Mon, 09 Feb 2026 20:03:18 +0000

Move `ResourceTables` constructors to `StoreOpaque` (#12546)* Move `ResourceTables` constructors to `StoreOpaque`This is intended to consolidate where they're constructed, provideaccess to the host data at all times, and pave the way for a futurerefactoring here to touch fewer lines.* Fix a cfg List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

c09aa380 - deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

Tue, 03 Feb 2026 19:13:45 +0000

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)* deprecate `[Typed]Func::post_return[_async]` and make them no-opsWith the advent of the Component Model concurrency ABI and it's `task.return`intrinsic, post-return functions have been informally deprecated and areexpected to be removed for WASI 1.0 and the corresponding stable edition of theComponent Model. Consequently, it does not make sense anymore to requireembedders to explicitly call the post-return function after using`[Typed]Func::call[_async]`.As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, thepost-return function is called automatically as part of`[Typed]Func::call[_async]` if present, which is how`[Typed]Func::call_concurrent` has worked all along. In addition, this commitfixes and tests a couple of cases where the task and/or thread was beingdisposed of before the post-return function was called.* address review feedback* test post-return function in more scenariosSpecifically, I've split the `invoke_post_return` test into multiple tests:- using `TypedFunc::call`- using `TypedFunc::call_async` with concurrency support enabled- using `TypedFunc::call_async` with concurrency support disabled- using `Func::call_async` with concurrency support disabled- using `TypedFunc::call_concurrent`* remove GCC/clang-specific deprecation attributeThis broke the MSVC build.* bless bindgen output* remove obsolete post-return functions and fieldsNow that post-return calls are handled internally without requiring explicitaction by the embedder, we can avoid unnecessary bookkeeping. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

bc4582c3 - Forbid rustdoc warnings in CI (#12420)

Tue, 27 Jan 2026 03:47:35 +0000

Forbid rustdoc warnings in CI (#12420)* Forbid rustdoc warnings in CIThis commit corrects our handling of rustdoc flags in CI to ensure thatwarnings indeed fire. Additionally this changes our flags to pass`-Dwarnings` to ensure that we have warning-free doc builds when allfeatures are enabled at least.There were quite a lot of preexisting issues to fix, so thisadditionally goes through and fixes all the warnings that cropped up.* Update nightly toolchain againprtest:full* Update another nightly* Fix a warning in generated code List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

21797bb5 - Refactor how concurrency support is enabled in a `Store` (#12416)

Fri, 23 Jan 2026 22:37:55 +0000

Refactor how concurrency support is enabled in a `Store` (#12416)* Document panics from using CM async machinery when CM async is not enabled* Refactor how concurrency support is enabled in a `Store`This commit is an extension/refactor of #12377 and #12379. Notably thisdecouples the runtime behavior of Wasmtime from enabled/disabledWebAssembly proposals. This enables the `wasmtime serve` subcommand, forexample, to continue to disallow component-model-async by default butcontinue to use `*_concurrent` under the hood.Specifically a new `Config::concurrency_support` knob is added. This isplumbed directly through to `Tunables` and takes over the preexisting`component_model_concurrency` field. This field configures whethertasks/etc are enabled at runtime for component-y things. The defaultvalue of this configuration option is the same as `cfg!(feature ="component-model-async")`, and this field is required ifcomponent-model-async wasm proposals are enabled. It's intended thateventually this'll affect on-by-default wasm features in Wasmtimedepending if the support is compiled in.This results in a subtle shift in behavior where component-model-asyncconcurrency is used by default now because the feature is turned on bydefault, even though the wasm features are off-by-default. This requiredadjusting a few indices expected in runtime tests due to tasks/threadsbeing allocated in index spaces.Finally, this additionally denies access at runtime to`Linker::*_concurrent` when concurrent support is disabled as otherwisethe various runtime data structures won't be initialized and panics willhappen.Closes #12393* Add a `-Wconcurrency-support` CLI flagUsed to update disas tests to show that, when disabled, old codegenquality is preserved* Ungate `Config` flag* Review comments---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

b271e452 - consistently create thread and task when entering component instance (#12379)

Fri, 23 Jan 2026 17:51:19 +0000

consistently create thread and task when entering component instance (#12379)* consistently create thread and task when entering component instancePreviously, we weren't creating a new thread or task in all cases when enteringa component instance, even when component model async features were enabled. Inparticular, entering an instance via a sync-to-sync, guest-to-guest adapter, via`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating athread or task, creating panics and/or instance mismatches in certain cases.This commit addresses all those cases and also adds assertions to all CM asyncintrinsics to verify that the caller instance matches the most-recently-pushedtask. Note that we still skip pushing and popping threads and tasks if no CMasync features are enabled in the `Config`.In order to populate the `GuestTask::instance` field for tasks created as partof `Linker::instantiate[_async]` calls, I had to add a`RuntimeComponentInstanceIndex` field to `GlobalInitializer::InstantiateModule`and friends so it would be available when needed.While testing this, I uncovered and fixed a couple of related issues:- We weren't checking the `may_leave` flag when guest-to-guest calling a resource destructor- We weren't checking whether a subtask was ready to delete (e.g. that no threads were still running) before attempting to delete it while deleting its supertask* fix warnings when component-model-async feature disabled* address review feedback* push a task when calling a resource dtor host-to-guest* add tests which call `thread.index` from realloc and post-return functions...and assert that the indexes match as expected.Getting the post-return test to pass required moving the call to`StoreOpaque::exit_sync_call` to after the post-return function is called. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

cc8d04f4 - Remove need for explicit `Config::async_support` knob (#12371)

Fri, 23 Jan 2026 02:46:45 +0000

Remove need for explicit `Config::async_support` knob (#12371)* Refactor component model host function definitionsPush the `async`-ness down one layer.* Remove need for explicit `Config::async_support` knobThis commit is an attempt to step towards reconciling "old async" and"new async" in Wasmtime. The old async style is the original asyncsupport in Wasmtime with `call_async`, `func_wrap_async`, etc, where themain property is that the store is "locked" during an async operation.Put another way, a store can only execute at most one async operation ata time. This is in contrast to "new async" support in Wasmtime with thecomponent-model-async (WASIp3) support, where stores can have more thanone async operation in flight at once.This commit does not fully reconcile these differences, but it doesremove one hurdle along the way: `Config::async_support`. Since thebeginning of Wasmtime this configuration knob has existed to explicitlydemarcate a config/engine/store as "this thing requires `async` stuffinternally." This has started to make less and less sense over timewhere the line between sync and async has become more murky with WASIp3where the two worlds comingle. The goal of this commit is to deprecate`Config::async_support` and make the function not actually do anything.In isolation this can't simply be done, however, because there are manyload-bearing aspects of Wasmtime that rely on this `async_support` knob.For example once epochs + yielding are enabled it's required that allWasm is executed on a fiber lest it hit an epoch and not know how toyield. That means that this commit is not a simple removal of`async_support` but instead a refactoring/rearchitecting of how async isused internally within Wasmtime. The high-level ideas within Wasmtimenow are:* A `Store` has a "requires async" boolean stored within it.* All configuration options which end up requiring async, such as yielding with epochs, turn this boolean on.* Creation of host functions which use async (e.g. `func_wrap_{async,concurrent}`) will also turn this option on.* Synchronous API entrypoints into Wasmtime ensure that this boolean is disabled.* Asynchronous APIs are usable at any time.This means that the concept of an async store vs a sync store is nowgone. All stores are equally capable of executing sync/async, and thechange now is that dynamically some stores will require that async isused with certain configuration. Additionally all panicking conditionsaround `async_support` have been converted to errors instead. Allrelevant APIs already returned an error and things are murky enough nowthat it's not necessarily trivial to get this right at the embedderlevel. In the interest of avoiding panics all detected async mismatchesare now first-class `wasmtime::Error` values.The end result of this commit is that `Config::async_support` is adeprecated `#[doc(hidden)]` function that does nothing. While manyinternal changes happened as well as having new tests for all this sortof behavior this is not expected to have a great impact on externalconsumers. In general a deletion of `async_support(true)` is in theoryall that's required. This is intended to make it easier to think aboutasync/sync/etc in the future with WASIp3 and eventually reconcile`func_wrap_async` and `func_wrap_concurrent` for example. That's leftfor future refactorings however.prtest:full* Review comments* Fix CI failures List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

63679896 - Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)

Thu, 22 Jan 2026 17:56:26 +0000

Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)* Only create `ConcurrentState` in a `Store` when CM async is enabledCreating the default `ConcurrentState` will create a `FuturesUnordered` whichwill allocate. By making this state optional, we can keep making progress onhttps://github.com/bytecodealliance/wasmtime/issues/12069, and put off dealingwith `FuturesUnordered` until when we are ready to try and make CM async codehandle OOMs.* Support dynamically disabling component-model-async at runtime* fix warnings in certain cfg builds* fix another warning* Forcibly enable CM async for a couple wast tests List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

b856261d - refactor recursive reentrance checks (#12349)

Wed, 14 Jan 2026 22:27:49 +0000

refactor recursive reentrance checks (#12349)* refactor recursive reentrance checksThis commit makes a few changes related to recursive reentrance checks, instancepoisoning, etc.:- Implements the more restrictive lift/lower rules described in https://github.com/WebAssembly/component-model/pull/589 such that a component instance may not lower a function lifted by one of its ancestors, nor vice-versa. Any such lower will result in a fused adapter which traps unconditionally, preventing guest-to-guest recursive reentrance without requiring data flow analysis. - Note that this required updating several WAST tests which were violating the new rule, including some in the `tests/component-model` Git submodule, which I've updated. - This is handled entirely in the `fact` module now; I've removed the `AlwaysTrap` case previously handled by `wasmtime-cranelift`.- Removes `FLAG_MAY_ENTER` from `InstanceFlags`. It is no longer needed for guest-to-guest calls due to the above, and for guest-to-host-to-guest calls we can rely on either `FLAG_NEEDS_POST_RETURN` for sync-lifted functions or the `GuestTask` call stack for async-lifted functions.- Adds a `StoreOpaque::trapped` field which is set when _any_ instance belonging to that store traps, at which point the entire store is considered poisoned, meaning no instance belonging to it may be entered. This prevents indeterminant concurrent task state left over from the trapping instance from leaking into other instances.Note that this does _not_ include code to push and pop `GuestTask` instances forguest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. thesynchronous `Func::call` API, so certain intrinsics which expect a `GuestTask`to be present such as `backpressure.inc` will still fail in such cases. I'lladdress that in a later PR.Also note that I made a small change to `wasmtime-wit-bindgen`, adding a `Send`bound on the `T` type parameter for `store | async` functions. This allowed meto recursively call `{Typed}Func::call_concurrent` from inside a host function,and it doesn't have any downsides AFAICT.Fixes #12128* bless bindgen expansions* bless disas tests* address review feedback* sync `trap.h` with `trap_encoding.rs`...and add const assertions to `trap.rs` to help avoid future divergence. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

b1c7887c - Update Func & TypedFunc's doc comments to explain Accessor and Store::run_concurrent (#12330)

Tue, 13 Jan 2026 01:20:11 +0000

Update Func & TypedFunc's doc comments to explain Accessor and Store::run_concurrent (#12330)* docs: explain Accessor and run_concurrent* Update crates/wasmtime/src/runtime/component/func/typed.rsCo-authored-by: Nick Fitzgerald * Update crates/wasmtime/src/runtime/component/func/typed.rsCo-authored-by: Nick Fitzgerald * chore: update comment formatting* chore: show func getter---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.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/component/func.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/component/func.rs

ec9b62ab - Enable borrowing components and stores mutable at the same time (#11987)

Fri, 07 Nov 2025 19:49:39 +0000

Enable borrowing components and stores mutable at the same time (#11987)* Use `OptionsIndex` more internally in componentsThis updates various runtimes bits for components to use `OptionsIndex`more aggressively and ultimately deletes the old `Options` type. The`Options` type is a heavyweight package of all possible options which iseffectively a duplication of what `OptionsIndex` points to, so that'sremoved in favor of directly accessing options.* Enable borrowing components and stores mutable at the same timeThis commit adds a new, safe, function to the `Instance` type forinternal use in Wasmtime which enables simultaneously borrowing the`Component`-within-the-`Instance` as well as the original store at thesame time. This is not possible to do in safe Rust when the store ismutable and must be implemented with `unsafe` code.The motivation for this commit is performance. In #11974 it wasdiscovered that the addition of a single `Arc::clone` was enough toreduce throughput in the embedding by 20%. While `Arc::clone` isgenerally cheap I can see how a "contended" `Arc::clone` could get quiteexpensive. This particular benchmark was running multiple instances ofthe same component across multiple threads which were all doing manyhost calls. Each host call, after the refactoring of #10959, containedan `Arc::clone` to the component itself. This in turn led to manythreads constantly incrementing/decrementing the `Arc::clone` count ofthe same `Arc` instance.At a high level this clone is not necessary. The component lives withinthe store and cannot be mutated/deleted during execution. Safe Rust,however, forbids access to the component and mutably using the store atthe same time. Thus, this helper function enters the picture. The goalhere is to remove the `Arc::clone` calls without requiring major surgeryor such to refactor the implementations of various functions throughoutWasmtime. The `unsafe` block used to implement this function documentsmore rationale as to why this should be safe.* Update crates/wasmtime/src/runtime/component/instance.rsCo-authored-by: Nick Fitzgerald ---------Co-authored-by: Nick Fitzgerald List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.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/component/func.rs

92126c50 - Add first-class type access of `component::Func` (#11943)

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

Add first-class type access of `component::Func` (#11943)When `Func:::{params,results}` was added we didn't have`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it'scheaper and easier to access and work with that instead of the one-offaccessors on `Func`. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs

d6e7841f - Document some known async pitfalls (#11871)

Thu, 16 Oct 2025 14:37:55 +0000

Document some known async pitfalls (#11871)* Document some known async pitfalls* `call_concurrent` is more like a "spawn" operation within a store so it cannot be cancelled by dropping the returned future.* `call_concurrent` cannot be cancelled today other than by dropping the whole store. This is the subject of #11833.* `call_concurrent` cannot make progress outside of `run_concurrent`.* `run_concurrent` does not properly implement "select" operations internally due to #11869 and #11870. This means that timeouts within `run_concurrent` will not work.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/func.rs