|
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, 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, v37.0.2, v37.0.1, v37.0.0, v36.0.2, v36.0.1, v36.0.0 |
|
| #
1155d6df |
| 28-Jul-2025 |
Alex Crichton <[email protected]> |
Redesign function configuration in `bindgen!` (#11328)
* Redesign function configuration in `bindgen!`
This commit is a redesign of how function-level configuration works in Wasmtime's `bindgen!` m
Redesign function configuration in `bindgen!` (#11328)
* Redesign function configuration in `bindgen!`
This commit is a redesign of how function-level configuration works in Wasmtime's `bindgen!` macro. The main goal of this redesign is to better support WASIp3 and component model async functions. Prior to this redesign there was a mish mash of mechanisms to configure behavior of imports/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 a hodgepodge of systems that organically grew over time. In my personal opinion it was in dire need of a refresh to take into account how component-model-async ended up being implemented as well as consolidating the one-off systems amongst all of these configuration keys. A major motivation of this redesign, for example, was to inherit behavior from WIT files by default. An `async` function in WIT should not require `concurrent_*` keys to be configured, but rather it should generate correct bindings by default.
In this commit, all of the above keys were removed. All keys have been replaced with `imports` and `exports` configuration keys. Each behaves the 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 configuration is 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<TheWitBindingType>`. If `trappable_errors` is applicable then it means just a `Result<TheWitOkType, TrappableErrorType>` 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 function being 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 is generated. For example the same split traits of today are still generated and it's controlled based on the flags. Note though that the previous `HostConcurrent` trait was renamed to `HostWithStore` to make space for synchronous functions in this trait in the future too.
The end result of all these changes is that configuring imports/exports now 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 work by default without further need to configure anything (unless more functionality 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 to the embedder to choose the appropriate one.
Closes #11246 Closes #11247
* Update expanded test expectations
prtest:full
* Fix the min platform embedding example
* Fix doc tests
* Always generate `*WithStore` traits
This helps when using the `with` mapping since that can always assume that `HostWithStore` is available in the generated bindings, avoiding the need to duplicate configuration options.
* Update test expectations
* Review comments
show more ...
|
|
Revision tags: v35.0.0, v24.0.4, v33.0.2, v34.0.2 |
|
| #
64bc3bd9 |
| 15-Jul-2025 |
Alex Crichton <[email protected]> |
Start to use `&Accessor<T, D>` more in concurrent code (#11238)
* Start to use `&Accessor<T, D>` more in concurrent code
After discussion with Joel we've concluded that while `&mut Accessor<T, D>`
Start to use `&Accessor<T, D>` more in concurrent code (#11238)
* Start to use `&Accessor<T, D>` more in concurrent code
After discussion with Joel we've concluded that while `&mut Accessor<T, D>` was originally added to model host functions it is also appropriate to use it to model embedder-rooted invocations of items such as wasm as well. Effectively the conclusion we reached was that `*::call_concurrent` should be taking `&Accessor`, not `StoreContextMut`. This has a number of benefits to it over the previous iteration:
* This makes exports behave more like imports where `Accessor` means "you're in the concurrent world".
* This makes exports have an `async fn` signature which is easier to read and understand.
* This automatically enforces the guarantee that the returned future is only polled within the main event loop because the future is always considered to close over the `&Accessor` provided meaning it statically cannot live outside of the event loop.
* This paves the way forward to future refactorings to avoid storing so much state within a `Store<T>` and instead try to store state directly in futures themselves. This should make cancellation more natural and eventually also remove `'static` bounds on params/results. Furthermore this should make it easier to avoid spawning tasks internally by storing state in futures instead of spawned tasks.
In doing this one of the main questions we were faced with was what to do about `&mut Accessor<T, D>`, namely the `mut` part. With a mutable accessor it would be only possible to call one function concurrently. One option considered was to add combinators like `Accessor::join` and `Accessor::race` but in the end we decided to avoid going that direction and instead switch to `&Accessor<T, D>` everywhere, freely enabling aliasing of the accessor. This has the downside that `Accessor::with` is now a relatively dangerous function in that it can panic, but idiomatic usage of it is not expected to panic as the distinction between the `async` and sync boundary of `Accessor` vs `StoreContextMut` is expected to naturally make the recursive panic condition of `with` rare to come up in practice.
Concrete changes in this commit are:
* `Accessor::with` now requires `&self`. * `Accessor::spawn` now requires `&self`. * Host functions are now given `&Accessor`, not `&mut Accessor`. * `{Typed,}Func::call_concurrent` is now an `async fn` which takes an `&Accessor` instead of `StoreContextMut`. * Guest bindings generation for concurrent invocations now looks exactly like async bindings generation except for replacing `StoreContextMut` with `Accessor`.
Note that this commit does not yet update the internal implementations of these functions to benefit from the new abilities that taking `&Accessor` implies. Instead that's deferred to a future update as necessary. Instead this is only updating the public API of the `wasmtime` crate to enable these refactorings in the future.
Also note that this does not yet update all functions to take `&Accessor`. Notably futures and streams still need to be updated.
cc #11224
* Review comments
---------
Co-authored-by: Joel Dice <[email protected]>
show more ...
|
| #
804060c8 |
| 11-Jul-2025 |
Joel Dice <[email protected]> |
add Component Model async ABI tests (#11136)
* add Component Model async ABI tests
This pulls in the tests from the `wasip3-prototyping` repo, minus the ones requiring WASIp3 support in `wasmtime-w
add Component Model async ABI tests (#11136)
* add Component Model async ABI tests
This pulls in the tests from the `wasip3-prototyping` repo, minus the ones requiring WASIp3 support in `wasmtime-wasi[-http]`, which will be PR'd separately.
* add audits and exemptions for new `component-async-tests` deps
In order to convince `cargo vet` that we only needed these deps to be `safe-to-run` (not necessarily `safe-to-deploy`, since it's test code), I've moved the `wasm-compose` dep to the `dev-dependencies` section of the `Cargo.toml` file, which required rearranging some code.
I've exempted `wasm-compose` since it's a BA project, and also exempted all but one of the remaining new deps since they each get well over 10,000 downloads per day from crates.io. I've audited and certified the remaining dep, `im-rc`, which came in a bit shy of the 10,000-per-day mark.
Signed-off-by: Joel Dice <[email protected]>
* simplify `component_async_tests::util::sleep`
Signed-off-by: Joel Dice <[email protected]>
---------
Signed-off-by: Joel Dice <[email protected]>
show more ...
|