|
Revision tags: dev, v36.0.9, v44.0.1, v43.0.2, v36.0.8, v24.0.8, v44.0.0, v43.0.1, v42.0.2, v36.0.7, v24.0.7, v43.0.0, v42.0.1, v41.0.4, v42.0.0, v40.0.4, v36.0.6, v24.0.6, v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3 |
|
| #
cc8d04f4 |
| 23-Jan-2026 |
Alex Crichton <[email protected]> |
Remove need for explicit `Config::async_support` knob (#12371)
* Refactor component model host function definitions
Push the `async`-ness down one layer.
* Remove need for explicit `Config::async
Remove need for explicit `Config::async_support` knob (#12371)
* Refactor component model host function definitions
Push the `async`-ness down one layer.
* Remove need for explicit `Config::async_support` knob
This commit is an attempt to step towards reconciling "old async" and "new async" in Wasmtime. The old async style is the original async support in Wasmtime with `call_async`, `func_wrap_async`, etc, where the main property is that the store is "locked" during an async operation. Put another way, a store can only execute at most one async operation at a time. This is in contrast to "new async" support in Wasmtime with the component-model-async (WASIp3) support, where stores can have more than one async operation in flight at once.
This commit does not fully reconcile these differences, but it does remove one hurdle along the way: `Config::async_support`. Since the beginning of Wasmtime this configuration knob has existed to explicitly demarcate a config/engine/store as "this thing requires `async` stuff internally." This has started to make less and less sense over time where the line between sync and async has become more murky with WASIp3 where 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 many load-bearing aspects of Wasmtime that rely on this `async_support` knob. For example once epochs + yielding are enabled it's required that all Wasm is executed on a fiber lest it hit an epoch and not know how to yield. That means that this commit is not a simple removal of `async_support` but instead a refactoring/rearchitecting of how async is used internally within Wasmtime. The high-level ideas within Wasmtime now 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 now gone. All stores are equally capable of executing sync/async, and the change now is that dynamically some stores will require that async is used with certain configuration. Additionally all panicking conditions around `async_support` have been converted to errors instead. All relevant APIs already returned an error and things are murky enough now that it's not necessarily trivial to get this right at the embedder level. In the interest of avoiding panics all detected async mismatches are now first-class `wasmtime::Error` values.
The end result of this commit is that `Config::async_support` is a deprecated `#[doc(hidden)]` function that does nothing. While many internal changes happened as well as having new tests for all this sort of behavior this is not expected to have a great impact on external consumers. In general a deletion of `async_support(true)` is in theory all that's required. This is intended to make it easier to think about async/sync/etc in the future with WASIp3 and eventually reconcile `func_wrap_async` and `func_wrap_concurrent` for example. That's left for future refactorings however.
prtest:full
* Review comments
* Fix CI failures
show more ...
|
|
Revision tags: v41.0.0, v36.0.4, v39.0.2, v40.0.2, v40.0.1, v40.0.0, v39.0.1, v39.0.0, v38.0.4, v37.0.3, v36.0.3, v24.0.5, v38.0.3, v38.0.2, v38.0.1 |
|
| #
33224b22 |
| 17-Oct-2025 |
Alex Crichton <[email protected]> |
Use the same `cc` extension for C++ files (#11881)
* Use the same `cc` extension for C++ files
Rename a few stragglers using `*.cpp` to `*.cc` to have consistent syntax throughout the repository.
Use the same `cc` extension for C++ files (#11881)
* Use the same `cc` extension for C++ files
Rename a few stragglers using `*.cpp` to `*.cc` to have consistent syntax throughout the repository.
* Fix another reference
* Rename more extensions
show more ...
|