Changes in stack_creator.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/tests/all/stack_creator.rs

94740588 - Migrate the Wasmtime CLI to `wasmtime::error` (#12295)

Fri, 09 Jan 2026 19:15:48 +0000

Migrate the Wasmtime CLI to `wasmtime::error` (#12295)* Migrate wasmtime-cli to `wasmtime::error`* migrate benches to `wasmtime::error` as well* Remove new usage of anyhow that snuck in List of files: /wasmtime-44.0.1/tests/all/stack_creator.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/tests/all/stack_creator.rs

e657756d - Run CI tests through AddressSanitizer (#10537)

Thu, 10 Apr 2025 15:35:08 +0000

Run CI tests through AddressSanitizer (#10537)This is similar to running tests in Valgrind (which we should perhapsalso do...) but can be useful for catching use-after-free style bugsfaster than when a process crashes. Given the unsafe nature of Wasmtimethis is something we should have probably enabled awhile back butotherwise so long as it doesn't take too long to run on CI seems like aneasy win of a boost-of-confidence.prtest:asan List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs

980a136e - Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)

Thu, 16 Jan 2025 00:23:13 +0000

Wasmtime: generalize `async_stack_zeroing` knob to cover initialization (#10027)* Wasmtime: generalize `async_stack_zeroing` knob to cover initializationThis commit moves the knob from the `PoolingInstanceAllocatorConfig` to theregular `Config` and now controls both whether stacks are zeroed before reuseand whether they are zeroed before the initial use. The latter doesn't matterusually, since anonymous mmaps are already zeroed so we don't have to doanything there, but for no-std environments it is the difference betweenmanually zeroing the stack or simply using unininitialized memory.* Fix CLI and test builds* fix default config value* fix some more tests List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs

110e70f3 - Print an error on async stack overflow (#9304)

Thu, 26 Sep 2024 04:12:12 +0000

Print an error on async stack overflow (#9304)* Print an error on async stack overflowThis commit updates Wasmtime's handling of traps on Unix platforms toprint an error message on stack overflow when the guard page is hit.This is distinct from stack overflow in WebAssembly which raises anormal trap and can be caught. This is instead to be used onmisconfigured hosts where the async stack is too small or wasm wasallowed to take up too much of the async stack. Currently no errormessage is printed and the program simply aborts with a core dump whichcan be difficult to debug.This instead registers the range of the async guard page with the traphandling infrastructure to test the faulting address and if it lieswithin this range. If so then a small message is printed and then theprogram is aborted with `libc::abort()`.This does not impact the safety of any prior embedding or fix anyissues. It's instead intended purely as a diagnostic tool to help usersmore quickly understand that stack size configuration settings are thelikely culprit.* Fix build of c-api and testsprtest:full* Fix build on Windows* Fix a warning on Windows* Fix dead code on miri List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs

8652011f - Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)

Fri, 09 Feb 2024 21:07:52 +0000

Refactor `wasmtime::FuncType` to hold a handle to its registered type (#7892)* Refactor `wasmtime::FuncType` to hold a handle to its registered typeRather than holding a copy of the type directly, it now holds a `RegisteredType`which internally is* A `VMSharedTypeIndex` pointing into the engine's types registry.* An `Arc` handle to the engine's type registry.* An `Arc` handle to the actual type.The last exists only to keep it so that accessing a `wasmtime::FuncType`'sparameters and results fast, avoiding any new locking on call hot paths.This is helping set the stage for further types and `TypeRegistry` refactorsneeded for Wasm GC.* Update the C API for the function types refactorprtest:full* rustfmt* Fix benches build List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs

f7d16d81 - clarify custom memory needs to be zero filled (#7565)

Tue, 21 Nov 2023 05:26:12 +0000

clarify custom memory needs to be zero filled (#7565)Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs

e6ff8411 - Introduce API for custom stack memory (#7209)

Wed, 11 Oct 2023 19:35:42 +0000

Introduce API for custom stack memory (#7209)* Introduce StackMemory and StackMemoryCreatorThis allows custom implementations of stack memory to be plugged intothe async functionality for wasmtime. Currently, stacks are alwaysmmapped, and this custom allocator allows embedders to use any memorythey would like.The new APIs are also exposed in the C api.This has no effect on windows, as our hands are tied with fibers there.Signed-off-by: Tyler Rockwood * Add test for custom host memorySigned-off-by: Tyler Rockwood * fix allocator testSigned-off-by: Tyler Rockwood * Address review commentsSigned-off-by: Tyler Rockwood * Fix lint warningsprtest:fullSigned-off-by: Tyler Rockwood * fix windows lint warningprtest:fullSigned-off-by: Tyler Rockwood ---------Signed-off-by: Tyler Rockwood List of files: /wasmtime-44.0.1/tests/all/stack_creator.rs