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

fb1827ee - `wit-bindgen`: Add an option to use `anyhow::Result` instead of `wasmtime::Result` (#12331)

Tue, 13 Jan 2026 18:46:48 +0000

`wit-bindgen`: Add an option to use `anyhow::Result` instead of `wasmtime::Result` (#12331)* wit-bindgen: Add an option to use `anyhow::Result` instead of `wasmtime::Result`* Add option to reference docs* Rename `anyhow` dev dependency to `anyhow-for-testing` List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.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/mod.rs

f586be11 - cm-async: Start to fill out `{Future,Stream}Any` (#12142)

Tue, 09 Dec 2025 18:24:05 +0000

cm-async: Start to fill out `{Future,Stream}Any` (#12142)* cm-async: Start to fill out `{Future,Stream}Any`This commit is the first step down the road of filling out thepreexisting, but empty/buggy, `FutureAny` and `StreamAny` types. Theseare intended to behave similarly to `ResourceAny` where the embedderdoesn't have static knowledge ahead of time about the type of thefuture/stream in use. Changes made here are:* `ComponentType for {Stream,Future}Reader` now correctly typecheck the `T`.* Conversion to/from `*Any` types now properly typechecks the payload type against the expected type.* `{Future,Stream}Any` now live in their own file with the matrix of conversions to the typed variants.* A `close` method was added to `*Any` types.These types are not currently directly constructible but this willlikely be relaxed in the future. Additionally the host can't actuallyuse these values without knowing the type, which is another restrictionthat will be relaxed in the future (aka implemented).cc #11161* Fix tests* Skip a test on miri List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

020727d0 - Update wasm-tools dependencies (#12031)

Fri, 14 Nov 2025 21:34:45 +0000

Update wasm-tools dependencies (#12031)* Change separator style* Update wasm-tools dependencies* Also update wit-bindgen* Drop `[async]` name prefixes* Plumb `async` as part of a function typeRuntime handling of async functions and new traps are to be implementedin subsequent commits. This is just getting everything running again.* Run clang-format, also add test* Fix some more wast tests---------Co-authored-by: Sy Brand List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.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/mod.rs

8c03849b - Use `.` instead of `/` for interface members. (#11947)

Mon, 27 Oct 2025 21:23:36 +0000

Use `.` instead of `/` for interface members. (#11947)* Use `.` instead of `/` for interface members.In the `wasmtime::component::generate` macro, change the syntax forreferencing functions and types inside interfaces to use `.` insteadof `/`.For example, this changes strings like `wasi:http/types/outgoing-body`to `wasi:http/types.outgoing-body`.This makes the syntax more consistent with the syntax of[WIT `use` statements], which use `.` for this purpose.And, it avoids an incompatibility with the future nested namespaces syntax([��]), where the `/d` in `a:b/c/d` is for traversing a component exportrather than an interface member.[WIT `use` statements]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/WIT.md#wit-packages-and-use[��]: https://github.com/WebAssembly/component-model/blob/main/design/mvp/Explainer.md#gated-features* Use the new syntax in more places.* Revert changes to vendored WIT files.* Revert more changes to vendored files.* Update syntax in more places. List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

c14dd11b - Add a new `ResourceDynamic` type (#11885)

Mon, 20 Oct 2025 17:21:50 +0000

Add a new `ResourceDynamic` type (#11885)* Move `ResourceAny` to its own submoduleIn preparation for upcoming other refactorings...* Move `Resource` to its own submodule* Move `ResourceType` to its own submodule* Move host resource table infrastructure to its own module* Add module documentation to resource-related modules* Add a new `ResourceDynamic` typeThis commit adds a new type `wasmtime::component::ResourceDynamic` tothe embedding API which internally is more-or-less the same as`Resource` but with different type information. This`ResourceDynamic` specifically enables storing runtime information formanaging the type of the resource as opposed to `Resource` whichrequires static information.The main goal of this type is to enable exposing resources in the C APIof Wasmtime. Currently there is no way to define different resourcetypes in the C API because the only option is `Resource`. With thistype it will be possible to create distinct resource types in the C APIfor embedders to use.cc #11437* Apply suggestions from code reviewCo-authored-by: Joel Dice ---------Co-authored-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

a80bbdf9 - Rename trappable_imports to trappable in macro documentation (#11674)

Wed, 10 Sep 2025 22:07:05 +0000

Rename trappable_imports to trappable in macro documentation (#11674) List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

080faa1a - add `task_exit` option to `wasmtime-wit-bindgen` (#11665)

Wed, 10 Sep 2025 20:27:13 +0000

add `task_exit` option to `wasmtime-wit-bindgen` (#11665)This builds on #11662 by optionally exposing the `TaskExit` return value from`[Typed]Func::call_concurrent` in the bindings generated for exported functions.Note that the first two commits are shared with #11662.Fixes #11600Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

5764da5f - Revamp component model stream/future host API (again) (#11515)

Thu, 04 Sep 2025 21:12:18 +0000

Revamp component model stream/future host API (again) (#11515)* Revamp component model stream/future host API (again)This changes the host APIs for dealing with futures and streams from a"rendezvous"-style API to a callback-oriented one.Previously you would create e.g. a `StreamReader`/`StreamWriter` pair and calltheir `read` and `write` methods, respectively, and those methods would return`Future`s that resolved when the operation was matched with a corresponding`write` or `read` operation on the other end.With the new API, you instead provide a `StreamProducer` trait implementationwhe creating the stream, whose `produce` method will be called as soon as a readhappens, giving the implementation a chance to respond immediately withoutmaking the reader wait for a rendezvous. Likewise, you can match the read endof a stream to a `StreamConsumer` to respond immediately to writes. This modelshould reduce scheduling overhead and make it easier to e.g. pipe items to/from`AsyncWrite`/`AsyncRead` or `Sink`/`Stream` implementations without needing toexplicitly spawn background tasks. In addition, the new API provides directaccess to guest read and write buffers for `stream` operations, enablingzero-copy operations.Other changes:- I've removed the `HostTaskOutput`; we were using it to run extra code with access to the store after a host task completes, but we can do that more elegantly inside the future using `tls::get`. This also allowed me to simplify `Instance::poll_until` a bit.- I've removed the `watch_{reader,writer}` functionality; it's not needed now given that the runtime will automatically dispose of the producer or consumer when the other end of the stream or future is closed -- no need for embedder code to manage that.- In order to make `UntypedWriteBuffer` `Send`, I had to wrap its raw pointer `buf` field in a `SendSyncPtr`.- I've removed `{Future,Stream}Writer` entirely and moved `Instance::{future,stream}` to `{Future,Stream}Reader::new`, respectively.- I've added a bounds check to the beginnings of `Instance::guest_read` and `Instance::guest_write` so that we need not do it later in `Guest{Source,Destination}::remaining`, meaning those functions can be infallible.Note that I haven't updated `wasmtime-wasi` yet to match; that will happen inone or more follow-up commits.Signed-off-by: Joel Dice * Add `Accessor::getter`, rename `with_data` to `with_getter`* fixup bindgen invocationSigned-off-by: Roman Volosatovs * add support for zero-length writes/reads to/from hostI've added a test to cover this; it also tests direct buffer access for`stream`, which I realized I forgot to cover earlier. And of course therewas a bug :facepalm:.Signed-off-by: Joel Dice * add `{Destination,Source}::remaining` methodsThis can help `Stream{Producer,Consumer}` implementations determine how manyitems to write or read, respectively.Signed-off-by: Joel Dice * wasi: migrate sockets to new APISigned-off-by: Roman Volosatovs * tests: read the socket stream until EOFSigned-off-by: Roman Volosatovs * p3-sockets: account for cancellationSigned-off-by: Roman Volosatovs * p3-sockets: mostly ensure byte buffer cancellation-safetySigned-off-by: Roman Volosatovs * p3-filesystem: switch to new APISigned-off-by: Roman Volosatovs * fixup! p3-sockets: mostly ensure byte buffer cancellation-safety* p3-cli: switch to new APISigned-off-by: Roman Volosatovs * p3: limit maximum buffer sizeSigned-off-by: Roman Volosatovs * p3-sockets: remove reuseaddr test loop workaroundSigned-off-by: Roman Volosatovs * p3: drive I/O in `when_ready`Signed-off-by: Roman Volosatovs * fixup! p3: drive I/O in `when_ready`* Refine `Stream{Producer,Consumer}` APIsPer conversations last week with Roman, Alex, and Lann, I've updated thesetraits to present a lower-level API based on `poll_{consume,produce}` functionsand have documented the implementation requirements for various scenarios whichhave come up in `wasmtime-wasi`, particularly around graceful cancellation. Seethe doc comments for those functions for details.Signed-off-by: Joel Dice * being integration of new APISigned-off-by: Roman Volosatovs * update wasi/src/p3/filesystem to use new stream APIThis is totally untested so far; I'll run the tests once we have everything elsecompiling.Signed-off-by: Joel Dice * update wasi/src/p3/cli to use new stream APIThis is totally untested and doesn't even compile yet due to a lifetime issue Idon't have time to address yet. I'll follow up later with a fix.Signed-off-by: Joel Dice * fix: remove `'a` bound on `&self`Signed-off-by: Roman Volosatovs * finish `wasi:sockets` adaptationSigned-off-by: Roman Volosatovs * finish `wasi:cli` adaptationNote, that this removes the read optimization - let's get theimplementation complete first and optimize laterSigned-off-by: Roman Volosatovs * remove redundant loop in socketsSigned-off-by: Roman Volosatovs * wasi: buffer on 0-length readsSigned-off-by: Roman Volosatovs * finish `wasi:filesystem` adaptationSigned-off-by: Roman Volosatovs * remove `MAX_BUFFER_CAPACITY`Signed-off-by: Roman Volosatovs * refactor `Cursor` usageSigned-off-by: Roman Volosatovs * impl Default for VecBufferSigned-off-by: Roman Volosatovs * refactor: use consistent import stylingSigned-off-by: Roman Volosatovs * feature-gate fs Arc accessorsSigned-off-by: Roman Volosatovs * Update test expectations---------Signed-off-by: Joel Dice Signed-off-by: Roman Volosatovs Co-authored-by: Alex Crichton Co-authored-by: Roman Volosatovs List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

c42ed27a - Refactor `AbortHandle`, renamed to `JoinHandle` (#11414)

Tue, 12 Aug 2025 03:30:55 +0000

Refactor `AbortHandle`, renamed to `JoinHandle` (#11414)* Refactor `AbortHandle`, renamed to `JoinHandle`This commit is inspired by recent discussions about providing moreguarantees around dropping WASI resources. This commit renames`wasmtime::component::AbortHandle` to `wasmtime::component::JoinHandle`and additionally implements `Future for JoinHandle` to know when theassociated task's future has been dropped. The renaming is intended tomore closely align with `tokio::task::JoinHandle` where`tokio::task::AbortHandle` is notably different and doesn't have a`Future` implementation. The `Future` implementation helps embeddersknow exactly when a value has been dropped and synchronize on that.* Clarify lack of abort-on-drop behavior List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

b4475438 - refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)

Wed, 30 Jul 2025 16:40:41 +0000

refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)* refactor `{Stream,Future}|{Reader,Writer}` APIs and internalsThis makes a several changes to how `{Stream,Future}|{Reader,Writer}` work tomake them more efficient and, in some ways, more ergonomic:- The background tasks have been removed, allowing reads and writes to complete without task context switching. We now only allocate and use oneshot channels lazily when the other end is not yet ready; this improves real world performance benchmarks (e.g. wasi-http request handling) considerably.- Instances of `{Stream,Future}Reader` can now be lifted and lowered directly; no need for `Host{Stream,Future}` anymore.- The type parameter for `Stream{Reader,Writer}` no longer refers to the buffer type -- just the payload type (i.e. `StreamReader` instead of `StreamReader>`), meaning any buffer type may be used for a given read or write operation. This also means the compiler needs help with type inference less often when calling `Instance::stream`.- Instances of `{Stream,Future}|{Reader,Writer}` now require access to the store in order to be disposed of properly. I've added RAII wrapper structs (`WithAccessor[AndValue]`) to help with this, and also updated `Store::drop` and `Instance::run_concurrent` to ensure the store thread-local is set when dropping futures closing over `&Accessor`s.- In order to ensure that resources containing `{Stream,Future}|{Reader,Writer}` instances are disposed of properly, I've added `LinkerInstance::resource_concurrent` and have updated `wasmtime-wit-bindgen` to use it. This gives resource drop functions access to a `StoreContextMut` via an `Accessor`, allowing the stream and future handles to be disposed of. - In order to make this work, I had to change `Accessor::instance` from a `Instance` to an `Option`, which is awkward but temporary since we're planning to remove `Accessor::instance` entirely once we've moved concurrent state from `ComponentInstance` to `Store`.That problem of disposal is definitely the most awkward part of all this. Insimple cases, it's easy enough to ensure that read and write handles aredisposed of properly, but both `wasmtime-wasi` and `wasmtime-wasi-http` havesome pretty complicated functions where handles are passed between tasks and/orstored inside resources, so it can be tricky to ensure proper disposal on allcode paths. I'm open to ideas for improving this, but I suspect we'll need newRust language features (e.g. linear types) to make it truly ergonomic, robust,and efficient.While testing the above, I discovered an issue with `Instance::poll_until` suchthat it would prematurely give up and return a "deadlock" trap error, believingthat there was no further work to do, even though the future passed to it wasready to resolve the next time it was polled. I've fixed this by polling it onelast time and only trapping if it returns pending.Note that I've moved a few associated functions from `ConcurrentState` to`Instance` (e.g. `guest_drop_writable` and others) since they now need access tothe store; they're unchanged otherwise. Apologies for the diff noise.Finally, I've tweaked how `wasmtime serve` to poll the guest for content beforehanding the response to Hyper, which helps performance by ensuring the firstcontent chunk can be sent with the same TCP packet as the beginning of theresponse.Signed-off-by: Joel Dice fix wasi p3 build and test failuresSigned-off-by: Joel Dice use `ManuallyDrop` instead of `Option` in `Dropper`This allows us to drop its `value` field in-place, i.e. without moving it,thereby upholding the `Pin` guarantee.Signed-off-by: Joel Dice address review comments- Remove `DropWithStoreAndValue` and friends; go back to taking a `fn() -> T` parameter in `Instance::future` instead- Make `DropWithStore::drop[_with]` take `&mut self` instead of `self`- Make `WithAccessor` and `DropWithStore` private - Instead, I've added public `Guarded{Stream,Future}{Reader,Writer}` types for RAII - and also `{Stream,Future}{Reader,Writer}::close[_with]` methods- Use RAII in `FutureReader::read` and `FutureWriter::write` to ensure handles are dropped if the `Future` is droppedSigned-off-by: Joel Dice * lower host stream/future writes in background taskThis avoids unsoundness due to guest realloc calls while there are host embedderframes on the stack.Signed-off-by: Joel Dice * fix `tcp.rs` regressionsSigned-off-by: Joel Dice ---------Signed-off-by: Joel Dice List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

1155d6df - Redesign function configuration in `bindgen!` (#11328)

Mon, 28 Jul 2025 18:31:06 +0000

Redesign function configuration in `bindgen!` (#11328)* Redesign function configuration in `bindgen!`This commit is a redesign of how function-level configuration works inWasmtime's `bindgen!` macro. The main goal of this redesign is tobetter support WASIp3 and component model async functions. Prior to thisredesign there was a mish mash of mechanisms to configure behavior ofimports/exports:* The `async` configuration could turn everything async, nothing async, only some imports async, or everything except some imports async.* The `concurrent_{imports,exports}` keys were required to explicitly opt-in to component model async signatures and applied to all imports/exports.* The `trappable_imports` configuration would indicate a list of imports allowed to trap and it had special configuration for everything, nothing, and only a certain list.* The `tracing` and `verbose_tracing` keys could be applied to either nothing or all functions.Overall the previous state of configuration in `bindgen!` was clearly ahodgepodge of systems that organically grew over time. In my personalopinion it was in dire need of a refresh to take into account howcomponent-model-async ended up being implemented as well asconsolidating the one-off systems amongst all of these configurationkeys. A major motivation of this redesign, for example, was to inheritbehavior from WIT files by default. An `async` function in WIT shouldnot require `concurrent_*` keys to be configured, but rather it shouldgenerate correct bindings by default.In this commit, all of the above keys were removed. All keys have beenreplaced with `imports` and `exports` configuration keys. Each behavesthe same way and looks like so: bindgen!({ // ... imports: { // enable tracing for just this function "my:local/interface/func": tracing, // enable verbose tracing for just this function "my:local/interface/other-func": tracing | verbose_tracing, // this is blocking in WIT, but generate async bindings for // it "my:local/interface/[method]io.block": async, // like above, but use "concurrent" bindings which have // access to the store. "my:local/interface/[method]io.block-again": async | store, // everything else is, by default, trappable default: trappable, }, });Effectively all the function-level configuration items are now bitflags.These bitflags are by default inherited from the WIT files itself (e.g.`async` functions are `async | store` by default). Further configurationis then layered on top at the desires of the embedder. Supported keys are:* `async` - this means that a Rust-level `async` function should be generated. This is either `CallStyle::Async` or `CallStyle::Concurrent` as it was prior, depending on ...* `store` - this means that the generated function will have access to the store on the host. This is only implemented right now for `async | store` functions which map to `CallStyle::Concurrent`. In the future I'd like to support just-`store` functions which means that you could define a synchronous function with access to the store in addition to an asynchronous function.* `trappable` - this means that the function returns a `wasmtime::Result`. If `trappable_errors` is applicable then it means just a `Result` is returned (like before)* `tracing` - this enables `tracing!` integration for this function.* `verbose_tracing` - this logs all argument values for this function (including lists).* `ignore_wit` - this ignores the WIT-level defaults of the function (e.g. ignoring WIT `async`).The way this then works is all modeled is that for any WIT functionbeing generated there are a set of flags associated with that function.To calculate the flags the algorithm looks like:1. Find the first matching rule in the `imports` or `exports` map depending on if the function is imported or exported. If there is no matching rule then use the `default` rule if present. This is the initial set of flags for the function (or empty if nothing was found).2. If `ignore_wit` is present, return the flags from step 1. Otherwise add in `async | store` if the function is `async` in WIT.The resulting set of flags are then used to control how everything isgenerated. For example the same split traits of today are stillgenerated and it's controlled based on the flags. Note though that theprevious `HostConcurrent` trait was renamed to `HostWithStore` to makespace for synchronous functions in this trait in the future too.The end result of all these changes is that configuring imports/exportsnow uses the exact same selection system as the `with` replacement map,meaning there's only one system of selecting functions instead of 3.WIT-level `async` is now respected by default meaning that bindings workby default without further need to configure anything (unless morefunctionality is desired).One final minor change made here as well is that auto-generated`instantiate` methods are now always synchronous and an`instantiate_async` method is unconditionally generated for async mode.This means that bindings always generate both functions and it's up tothe embedder to choose the appropriate one.Closes #11246Closes #11247* Update expanded test expectationsprtest:full* Fix the min platform embedding example* Fix doc tests* Always generate `*WithStore` traitsThis helps when using the `with` mapping since that can always assumethat `HostWithStore` is available in the generated bindings, avoidingthe need to duplicate configuration options.* Update test expectations* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

c34eb3f7 - Require `Accessor` on all future/stream functions (#11250)

Wed, 16 Jul 2025 14:40:57 +0000

Require `Accessor` on all future/stream functions (#11250)* Require `Accessor` on all future/stream functionsThis is a follow-up to #11238 which adds `&Accessor` arguments to allfunctions for futures and streams. Like #11238 this is done to makefuture refactorings easier for the internal implementation but theinternal implementations are not updated at this time. Many functions,for example, do not use the argument at all just yet. The purpose ofthis is to ensure host usage of these functions always provides a storecontext.This change required large refactorings of the upcomingwasmtime-wasi-http implementation in the wasip3-prototyping repository.That's all been sorted out now though so the changes are being pulledback here into the Wasmtime repository as well.This commit additionally changes the `watch_*` functions on the variousstream/future types to take `&mut self` instead of `self`-by-value. This ismostly a stylistic change and is more API-driven than anything else.Functionally this behaves the same as before where, while watching, thestream/future cannot be read/written to otherwise.* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs

2b832281 - Gut `vm::Export` to mostly be `crate::Extern` (#11229)

Mon, 14 Jul 2025 21:05:01 +0000

Gut `vm::Export` to mostly be `crate::Extern` (#11229)* Remove `Table::from_wasmtime_table`This commit removes the unsafe function `Table::from_wasmtime_table`.This goes a bit further and removes `ExportTable` entirely as well whichmeans that table lookup on a `vm::Instance` directly returns a`wasmtime::Table` without any need to translate back-and-forth.* Remove `Tag::from_wasmtime_tag`Like the previous commit, but for tags.* Remove `Global::from_wasmtime_global`Like the previous commit, but for globals.* Remove `Memory::from_wasmtime_memory`Like the previous commit, but for memories.* Remove `Func::from_wasmtime_function`Like previous commits, but for functions.* Fix lints* Fill out missing safety comment* Review comments List of files: /wasmtime-44.0.1/crates/wasmtime/src/runtime/component/mod.rs