Changes in lib.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/wasi-threads/src/lib.rs

dcdbed12 - Migrate wasi-threads to `wasmtime::error` (#12275)

Wed, 07 Jan 2026 23:00:44 +0000

Migrate wasi-threads to `wasmtime::error` (#12275) List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

2bac6574 - Update the `log` dependency (#11197)

Mon, 07 Jul 2025 23:25:45 +0000

Update the `log` dependency (#11197)* Update the `log` dependencyThis enables getting warnings about formatting strings in the `log`crate directives which are then additionally fixed here as well.* Update dependency directive in `Cargo.toml` List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.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/wasi-threads/src/lib.rs

4005a813 - Make the Wasmtime CLI use async (#9184)

Thu, 29 Aug 2024 18:40:13 +0000

Make the Wasmtime CLI use async (#9184)* Make the Wasmtime CLI use asyncThis means that interrupting a running Wasm program will now workcorrectly, even when the program is blocked on I/O or waiting on a timeout orsome such.This also involved making `wasi-threads` async-compatible.Co-Authored-By: Alex Crichton * rustfmt* Make `run` command enable the `tokio` feature* Add a test for CLI, timeouts, and sleeping forever* Fix warning---------Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

a0442ea0 - Enforce `uninlined_format_args` for the workspace (#9065)

Mon, 05 Aug 2024 09:59:59 +0000

Enforce `uninlined_format_args` for the workspace (#9065)* Enforce `uninlined_format_args` for the workspace* fix: failing `Monolith Checks` job* fix: formatting List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

ff93bce0 - Wasmtime: Finish support for the typed function references proposal (#7943)

Tue, 20 Feb 2024 20:33:28 +0000

Wasmtime: Finish support for the typed function references proposal (#7943)* Wasmtime: Finish support for the typed function references proposalWhile we supported the function references proposal inside Wasm, we didn'tsupport it on the "outside" in the Wasmtime embedder APIs. So much of the workhere is exposing typed function references, and their type system updates, inthe embedder API. These changes include:* `ValType::FuncRef` and `ValType::ExternRef` are gone, replaced with the introduction of the `RefType` and `HeapType` types and a `ValType::Ref(RefType)` variant.* `ValType` and `FuncType` no longer implement `Eq` and `PartialEq`. Instead there are `ValType::matches` and `FuncType::matches` methods which check directional subtyping. I also added `ValType::eq` and `FuncType::eq` static methods for the rare case where someone needs to check precise equality, but that is almost never actually the case, 99.99% of the time you want to check subtyping.* There are also public `Val::matches_ty` predicates for checking if a value is an instance of a type, as well as internal helpers like `Val::ensure_matches_ty` that return a formatted error if the value does not match the given type. These helpers are used throughout Wasmtime internals now.* There is now a dedicated `wasmtime::Ref` type that represents reference values. Table operations have been updated to take and return `Ref`s rather than `Val`s.Furthermore, this commit also includes type registry changes to correctly managelifetimes of types that reference other types. This wasn't previously an issuebecause the only thing that could reference types that reference other types wasa Wasm module that added all the types that could reference each other at thesame time and removed them all at the same time. But now that the previouslydiscussed work to expose these things in the embedder API is done, type lifetimemanagement in the registry becomes a little trickier because the embedder mightgrab a reference to a type that references another type, and then unload theWasm module that originally defined that type, but then the user should still beable use that type and the other types it transtively references. Before, wewere refcounting individual registry entries. Now, we still are refcountingindividual entries, but now we are also accounting for type-to-type referencesand adding a new type to the registry will increment the refcounts of each ofthe types that it references, and removing a type from the registry willdecrement the refcounts of each of the types it references, and then recursively(logically, not literally) remove any types whose refcount has now reached zero.Additionally, this PR adds support for subtyping to `Func::typed`- and`Func::wrap`-style APIs. For result types, you can always use a supertype of theWebAssembly function's actual declared return type in `Func::typed`. And forparam types, you can always use a subtype of the Wasm function's actual declaredparam type. Doing these things essentially erases information but is alwayscorrect. But additionally, for functions which take a reference to a concretetype as a parameter, you can also use the concrete type's supertype. Consider aWebAssembly function that takes a reference to a function with a concrete type:`(ref null )`. In this scenario, there is no static`wasmtime::Foo` Rust type that corresponds to that particular Wasm-definedconcrete reference type because Wasm modules are loaded dynamically atruntime. You *could* do `f.typed::, ()>()`, and while that iscorrectly typed and valid, it is often overly restrictive. The only value youcould call the resulting typed function with is the null function reference, butwe'd like to call it with non-null function references that happen to be of thecorrect type. Therefore, `f.typed, ()>()` is also allowed in thiscase, even though `Option` represents `(ref null func)` which is thesupertype, not subtype, of `(ref null )`. This does imply someminimal dynamic type checks in this case, but it is supported for betterergonomics, to enable passing non-null references into the function.We can investigate whether it is possible to use generic type parameters andcombinators to define Rust types that precisely match concrete reference typesin future, follow-up pull requests. But for now, we've made things usable, atleast.Finally, this also takes the first baby step towards adding support for the WasmGC proposal. Right now the only thing that is supported is `nofunc` references,and this was mainly to make testing function reference subtyping easier. Butthat does mean that supporting `nofunc` references entailed also adding a`wasmtime::NoFunc` type as well as the `Config::wasm_gc(enabled)` knob. So weofficially have an in-progress implementation of Wasm GC in Wasmtime after thisPR lands!Fixes https://github.com/bytecodealliance/wasmtime/issues/6455* Fix WAT in test to be valid* Check that dependent features are enabled for function-references and GC* Remove unnecessary engine parameters from a few methodsEver since `FuncType`'s internal `RegisteredType` holds onto its own `Engine`,we don't need these anymore.Still useful to keep the `Engine` parameter around for the `ensure_matches`methods because that can be used to check correct store/engine usage forembedders.* Add missing dependent feature enabling for some tests* Remove copy-paste bit from test* match self to show it is uninhabited* Add a missing `is_v128` method* Short circuit a few func type comparisons* Turn comment into part of doc comment* Add test for `Global::new` and subtyping* Add tests for embedder API, tables, and subtyping* Add an embedder API test for setting globals and subtyping* Construct realloc's type from its index, rather than from scratch* Help LLVM better optimize our dynamic type checks in `TypedFunc::call_raw`* Fix call benchmark compilation* Change `WasmParams::into_abi` to take the whole func type instead of iter of params* Fix doc linksprtest:full* Fix size assertion on s390x List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

2b00a541 - Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)

Tue, 13 Feb 2024 17:57:58 +0000

Make wasi-common self-contained, deprecate exports from wasmtime-wasi (#7881)* WIP: try to make wasi-common self contained.* rebase: cargo.lock* remove all dependencies between wasi-common and wasmtime-wasi* use wasi-common directly throughout tests, benches, examples, cli run* wasi-threads: use wasi-common's maybe_exit_on_error in spawned threadnot a very modular design, but at this point wasi-common andwasi-threads are forever wed* fix wasmtime's docs* re-introduce wasmtime-wasi's exports of wasi-common definitions behind deprecated* factor out determining i32 process exit codeand remove libc dep because rustix provides the same constant* commands/run: inline the logic about aborting on trapsince this is the sole place in the codebase its used* Add high-level summary to wasi-common's top-level doc comment.* c-api: fix use of wasi_cap_std_sync => wasi_common::sync, wasmtime_wasi => wasi_common* fix tokio example* think better of combining downcast and masking into one method* fix references to wasmtime_wasi in docsprtest:full* benches: use wasi-common* cfg-if around use of rustix::process because that doesnt exist on windows* wasi-common: include tests, caught by verify-publish* fix another bench* exit requires wasmtime dep. caught by verify-publish. List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

9d487c5c - Allocate thread IDs for wasi_thread_spawn sequentially (#7884)

Mon, 12 Feb 2024 16:06:22 +0000

Allocate thread IDs for wasi_thread_spawn sequentially (#7884) List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

9aacf31a - wasi-threads: check module shape at spawn time (#6492)

Thu, 01 Jun 2023 15:24:01 +0000

wasi-threads: check module shape at spawn time (#6492)This change relaxes what kinds of modules can be run when wasi-threadsis enabled via `--wasi-modules experimental-wasi-threads`. Previously,as reported in #6153, simple modules that made no use of thread spawningor shared memories were preemptively rejected when the wasi-threadscontext was created. This is too restrictive.Instead, this change does the following:- it moves the check for whether a module is valid according to the wasi-threads specification to the point a new thread is spawned; this resolves #6153- as noted in #6153, this change also adds a better error message indicating that wasi-threads expects a shared memory import- the way this is implemented also improves the module instantiation: by constructing an `InstancePre` once when the `WasiThreadsCtx` is built, we might shave off a bit of time from the "spawn a thread" call; this supercedes a similar effort in #5741 List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

cacc4160 - wasi-threads: fix import name (#5748)

Wed, 08 Feb 2023 18:19:16 +0000

wasi-threads: fix import name (#5748)* wasi-threads: fix import name As @TerrorJack pointed out in #5484, that PR implements an older name--`thread_spawn`. This change uses the now-official name from the specification--`thread-spawn`. * fix: update name in test List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs

edfa10d6 - wasi-threads: an initial implementation (#5484)

Tue, 07 Feb 2023 21:43:02 +0000

wasi-threads: an initial implementation (#5484)This commit includes a set of changes that add initial support for `wasi-threads` to Wasmtime: * feat: remove mutability from the WasiCtx Table This patch adds interior mutability to the WasiCtx Table and the Table elements. Major pain points: * `File` only needs `RwLock` to implement `File::set_fdflags()` on Windows, because of [1] * Because `File` needs a `RwLock` and `RwLock*Guard` cannot be hold across an `.await`, The `async` from `async fn num_ready_bytes(&self)` had to be removed * Because `File` needs a `RwLock` and `RwLock*Guard` cannot be dereferenced in `pollable`, the signature of `fn pollable(&self) -> Option` changed to `fn pollable(&self) -> Option>` [1] https://github.com/bytecodealliance/system-interface/blob/da238e324e752033f315f09c082ad9ce35d42696/src/fs/fd_flags.rs#L210-L217 * wasi-threads: add an initial implementation This change is a first step toward implementing `wasi-threads` in Wasmtime. We may find that it has some missing pieces, but the core functionality is there: when `wasi::thread_spawn` is called by a running WebAssembly module, a function named `wasi_thread_start` is found in the module's exports and called in a new instance. The shared memory of the original instance is reused in the new instance. This new WASI proposal is in its early stages and details are still being hashed out in the [spec] and [wasi-libc] repositories. Due to its experimental state, the `wasi-threads` functionality is hidden behind both a compile-time and runtime flag: one must build with `--features wasi-threads` but also run the Wasmtime CLI with `--wasm-features threads` and `--wasi-modules experimental-wasi-threads`. One can experiment with `wasi-threads` by running: ```console $ cargo run --features wasi-threads -- \ --wasm-features threads --wasi-modules experimental-wasi-threads \ ``` Threads-enabled Wasm modules are not yet easy to build. Hopefully this is resolved soon, but in the meantime see the use of `THREAD_MODEL=posix` in the [wasi-libc] repository for some clues on what is necessary. Wiggle complicates things by requiring the Wasm memory to be exported with a certain name and `wasi-threads` also expects that memory to be imported; this build-time obstacle can be overcome with the `--import-memory --export-memory` flags only available in the latest Clang tree. Due to all of this, the included tests are written directly in WAT--run these with: ```console $ cargo test --features wasi-threads -p wasmtime-cli -- cli_tests ``` [spec]: https://github.com/WebAssembly/wasi-threads [wasi-libc]: https://github.com/WebAssembly/wasi-libc This change does not protect the WASI implementations themselves from concurrent access. This is already complete in previous commits or left for future commits in certain cases (e.g., wasi-nn). * wasi-threads: factor out process exit logic As is being discussed [elsewhere], either calling `proc_exit` or trapping in any thread should halt execution of all threads. The Wasmtime CLI already has logic for adapting a WebAssembly error code to a code expected in each OS. This change factors out this logic to a new function, `maybe_exit_on_error`, for use within the `wasi-threads` implementation. This will work reasonably well for CLI users of Wasmtime + `wasi-threads`, but embedders will want something better in the future: when a `wasi-threads` threads fails, they may not want their application to exit. Handling this is tricky, because it will require cancelling the threads spawned by the `wasi-threads` implementation, something that is not trivial to do in Rust. With this change, we defer that work until later in order to provide a working implementation of `wasi-threads` for experimentation. [elsewhere]: https://github.com/WebAssembly/wasi-threads/pull/17 * review: work around `fd_fdstat_set_flags` In order to make progress with wasi-threads, this change temporarily works around limitations induced by `wasi-common`'s `fd_fdstat_set_flags` to allow `&mut self` use in the implementation. Eventual resolution is tracked in https://github.com/bytecodealliance/wasmtime/issues/5643. This change makes several related helper functions (e.g., `set_fdflags`) take `&mut self` as well. * test: use `wait`/`notify` to improve `threads.wat` test Previously, the test simply executed in a loop for some hardcoded number of iterations. This changes uses `wait` and `notify` and atomic operations to keep track of when the spawned threads are done and join on the main thread appropriately. * various fixes and tweaks due to the PR review --------- Signed-off-by: Harald Hoyer Co-authored-by: Harald Hoyer Co-authored-by: Alex Crichton List of files: /wasmtime-44.0.1/crates/wasi-threads/src/lib.rs