|
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 |
|
| #
1e0b0b46 |
| 23-Feb-2026 |
Alex Crichton <[email protected]> |
Remove subtask reparenting (#12570)
This commit updates the implementation of component-model-async primitives to remove the manual subtask reparenting process. This is required to fix #12544 at a s
Remove subtask reparenting (#12570)
This commit updates the implementation of component-model-async primitives to remove the manual subtask reparenting process. This is required to fix #12544 at a semantic level because a subtask isn't ever actually reparented, even if its parent exits. The first part of this change is to remove the `GuestTask::subtasks` field and all relevant manipulations of it.
This field, however, powered the `TaskExit` abstraction returned from `call_concurrent`. This commit then subsequently deletes `TaskExit` and all related infrastructure as it's no longer directly applicable as-is. The rest of this change is then updating tests/bindings/etc to account for 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 #12544
prtest:full
show more ...
|
|
Revision tags: v41.0.3, v41.0.2, v41.0.1, v36.0.5, v40.0.3 |
|
| #
21797bb5 |
| 23-Jan-2026 |
Alex Crichton <[email protected]> |
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 `St
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 this decouples the runtime behavior of Wasmtime from enabled/disabled WebAssembly proposals. This enables the `wasmtime serve` subcommand, for example, to continue to disallow component-model-async by default but continue to use `*_concurrent` under the hood.
Specifically a new `Config::concurrency_support` knob is added. This is plumbed directly through to `Tunables` and takes over the preexisting `component_model_concurrency` field. This field configures whether tasks/etc are enabled at runtime for component-y things. The default value of this configuration option is the same as `cfg!(feature = "component-model-async")`, and this field is required if component-model-async wasm proposals are enabled. It's intended that eventually this'll affect on-by-default wasm features in Wasmtime depending if the support is compiled in.
This results in a subtle shift in behavior where component-model-async concurrency is used by default now because the feature is turned on by default, even though the wasm features are off-by-default. This required adjusting a few indices expected in runtime tests due to tasks/threads being allocated in index spaces.
Finally, this additionally denies access at runtime to `Linker::*_concurrent` when concurrent support is disabled as otherwise the various runtime data structures won't be initialized and panics will happen.
Closes #12393
* Add a `-Wconcurrency-support` CLI flag
Used to update disas tests to show that, when disabled, old codegen quality is preserved
* Ungate `Config` flag
* Review comments
---------
Co-authored-by: Nick Fitzgerald <[email protected]>
show more ...
|
| #
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 ...
|
| #
63679896 |
| 22-Jan-2026 |
Nick Fitzgerald <[email protected]> |
Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)
* Only create `ConcurrentState` in a `Store` when CM async is enabled
Creating the default `ConcurrentState` will create
Only create `ConcurrentState` in a `Store` when CM async is enabled (#12377)
* Only create `ConcurrentState` in a `Store` when CM async is enabled
Creating the default `ConcurrentState` will create a `FuturesUnordered` which will allocate. By making this state optional, we can keep making progress on https://github.com/bytecodealliance/wasmtime/issues/12069, and put off dealing with `FuturesUnordered` until when we are ready to try and make CM async code handle 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
show more ...
|
|
Revision tags: v41.0.0 |
|
| #
b856261d |
| 14-Jan-2026 |
Joel Dice <[email protected]> |
refactor recursive reentrance checks (#12349)
* refactor recursive reentrance checks
This commit makes a few changes related to recursive reentrance checks, instance poisoning, etc.:
- Implements
refactor recursive reentrance checks (#12349)
* refactor recursive reentrance checks
This commit makes a few changes related to recursive reentrance checks, instance poisoning, 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 for guest-to-guest sync-to-sync calls, nor for host-to-guest calls using e.g. the synchronous `Func::call` API, so certain intrinsics which expect a `GuestTask` to be present such as `backpressure.inc` will still fail in such cases. I'll address 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 me to 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.
show more ...
|
|
Revision tags: v36.0.4, v39.0.2, v40.0.2 |
|
| #
fb1827ee |
| 13-Jan-2026 |
Nick Fitzgerald <[email protected]> |
`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 refere
`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`
show more ...
|
|
Revision tags: v40.0.1 |
|
| #
96e19700 |
| 07-Jan-2026 |
Nick Fitzgerald <[email protected]> |
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 `wasmtim
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, redirects our top-level `wasmtime::{Error, Result}` re-exports to re-export `wasmtime::error::{Error, Result}`, and updates various use sites that were directly using `anyhow` to use the new `wasmtime` versions.
This process also required updating the component macro and wit-bindgen macro to use 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
show more ...
|
|
Revision tags: v40.0.0 |
|
| #
f586be11 |
| 09-Dec-2025 |
Alex Crichton <[email protected]> |
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 the preexisting, but empty/bu
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 the preexisting, but empty/buggy, `FutureAny` and `StreamAny` types. These are intended to behave similarly to `ResourceAny` where the embedder doesn't have static knowledge ahead of time about the type of the future/stream in use. Changes made here are:
* `ComponentType for {Stream,Future}Reader<T>` 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 will likely be relaxed in the future. Additionally the host can't actually use these values without knowing the type, which is another restriction that will be relaxed in the future (aka implemented).
cc #11161
* Fix tests
* Skip a test on miri
show more ...
|
|
Revision tags: v39.0.1, v39.0.0 |
|
| #
020727d0 |
| 14-Nov-2025 |
Alex Crichton <[email protected]> |
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 ty
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 type
Runtime handling of async functions and new traps are to be implemented in 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 <[email protected]>
show more ...
|
|
Revision tags: v38.0.4, v37.0.3, v36.0.3, v24.0.5 |
|
| #
ec9b62ab |
| 07-Nov-2025 |
Alex Crichton <[email protected]> |
Enable borrowing components and stores mutable at the same time (#11987)
* Use `OptionsIndex` more internally in components
This updates various runtimes bits for components to use `OptionsIndex`
Enable borrowing components and stores mutable at the same time (#11987)
* Use `OptionsIndex` more internally in components
This 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 is effectively a duplication of what `OptionsIndex` points to, so that's removed in favor of directly accessing options.
* Enable borrowing components and stores mutable at the same time
This commit adds a new, safe, function to the `Instance` type for internal use in Wasmtime which enables simultaneously borrowing the `Component`-within-the-`Instance` as well as the original store at the same time. This is not possible to do in safe Rust when the store is mutable and must be implemented with `unsafe` code.
The motivation for this commit is performance. In #11974 it was discovered that the addition of a single `Arc::clone` was enough to reduce throughput in the embedding by 20%. While `Arc::clone` is generally cheap I can see how a "contended" `Arc::clone` could get quite expensive. This particular benchmark was running multiple instances of the same component across multiple threads which were all doing many host calls. Each host call, after the refactoring of #10959, contained an `Arc::clone` to the component itself. This in turn led to many threads constantly incrementing/decrementing the `Arc::clone` count of the same `Arc` instance.
At a high level this clone is not necessary. The component lives within the store and cannot be mutated/deleted during execution. Safe Rust, however, forbids access to the component and mutably using the store at the same time. Thus, this helper function enters the picture. The goal here is to remove the `Arc::clone` calls without requiring major surgery or such to refactor the implementations of various functions throughout Wasmtime. The `unsafe` block used to implement this function documents more rationale as to why this should be safe.
* Update crates/wasmtime/src/runtime/component/instance.rs
Co-authored-by: Nick Fitzgerald <[email protected]>
---------
Co-authored-by: Nick Fitzgerald <[email protected]>
show more ...
|
| #
8c03849b |
| 27-Oct-2025 |
Dan Gohman <[email protected]> |
Use `.` instead of `/` for interface members. (#11947)
* Use `.` instead of `/` for interface members.
In the `wasmtime::component::generate` macro, change the syntax for referencing functions and
Use `.` instead of `/` for interface members. (#11947)
* Use `.` instead of `/` for interface members.
In the `wasmtime::component::generate` macro, change the syntax for referencing functions and types inside interfaces to use `.` instead of `/`.
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 export rather 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.
show more ...
|
|
Revision tags: v38.0.3, v38.0.2 |
|
| #
c14dd11b |
| 20-Oct-2025 |
Alex Crichton <[email protected]> |
Add a new `ResourceDynamic` type (#11885)
* Move `ResourceAny` to its own submodule
In preparation for upcoming other refactorings...
* Move `Resource<T>` to its own submodule
* Move `ResourceTy
Add a new `ResourceDynamic` type (#11885)
* Move `ResourceAny` to its own submodule
In preparation for upcoming other refactorings...
* Move `Resource<T>` 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` type
This commit adds a new type `wasmtime::component::ResourceDynamic` to the embedding API which internally is more-or-less the same as `Resource<T>` but with different type information. This `ResourceDynamic` specifically enables storing runtime information for managing the type of the resource as opposed to `Resource<T>` which requires static information.
The main goal of this type is to enable exposing resources in the C API of Wasmtime. Currently there is no way to define different resource types in the C API because the only option is `Resource<T>`. With this type it will be possible to create distinct resource types in the C API for embedders to use.
cc #11437
* Apply suggestions from code review
Co-authored-by: Joel Dice <[email protected]>
---------
Co-authored-by: Joel Dice <[email protected]>
show more ...
|
|
Revision tags: v38.0.1, v37.0.2, v37.0.1, v37.0.0 |
|
| #
a80bbdf9 |
| 10-Sep-2025 |
Andrzej Ressel <[email protected]> |
Rename trappable_imports to trappable in macro documentation (#11674)
|
| #
080faa1a |
| 10-Sep-2025 |
Joel Dice <[email protected]> |
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 e
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 #11600
Signed-off-by: Joel Dice <[email protected]>
show more ...
|
| #
5764da5f |
| 04-Sep-2025 |
Joel Dice <[email protected]> |
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 "rendez
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 call their `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 implementation whe creating the stream, whose `produce` method will be called as soon as a read happens, giving the implementation a chance to respond immediately without making the reader wait for a rendezvous. Likewise, you can match the read end of a stream to a `StreamConsumer` to respond immediately to writes. This model should reduce scheduling overhead and make it easier to e.g. pipe items to/from `AsyncWrite`/`AsyncRead` or `Sink`/`Stream` implementations without needing to explicitly spawn background tasks. In addition, the new API provides direct access to guest read and write buffers for `stream<u8>` operations, enabling zero-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 in one or more follow-up commits.
Signed-off-by: Joel Dice <[email protected]>
* Add `Accessor::getter`, rename `with_data` to `with_getter`
* fixup bindgen invocation
Signed-off-by: Roman Volosatovs <[email protected]>
* add support for zero-length writes/reads to/from host
I've added a test to cover this; it also tests direct buffer access for `stream<u8>`, which I realized I forgot to cover earlier. And of course there was a bug :facepalm:.
Signed-off-by: Joel Dice <[email protected]>
* add `{Destination,Source}::remaining` methods
This can help `Stream{Producer,Consumer}` implementations determine how many items to write or read, respectively.
Signed-off-by: Joel Dice <[email protected]>
* wasi: migrate sockets to new API
Signed-off-by: Roman Volosatovs <[email protected]>
* tests: read the socket stream until EOF
Signed-off-by: Roman Volosatovs <[email protected]>
* p3-sockets: account for cancellation
Signed-off-by: Roman Volosatovs <[email protected]>
* p3-sockets: mostly ensure byte buffer cancellation-safety
Signed-off-by: Roman Volosatovs <[email protected]>
* p3-filesystem: switch to new API
Signed-off-by: Roman Volosatovs <[email protected]>
* fixup! p3-sockets: mostly ensure byte buffer cancellation-safety
* p3-cli: switch to new API
Signed-off-by: Roman Volosatovs <[email protected]>
* p3: limit maximum buffer size
Signed-off-by: Roman Volosatovs <[email protected]>
* p3-sockets: remove reuseaddr test loop workaround
Signed-off-by: Roman Volosatovs <[email protected]>
* p3: drive I/O in `when_ready`
Signed-off-by: Roman Volosatovs <[email protected]>
* fixup! p3: drive I/O in `when_ready`
* Refine `Stream{Producer,Consumer}` APIs
Per conversations last week with Roman, Alex, and Lann, I've updated these traits to present a lower-level API based on `poll_{consume,produce}` functions and have documented the implementation requirements for various scenarios which have come up in `wasmtime-wasi`, particularly around graceful cancellation. See the doc comments for those functions for details.
Signed-off-by: Joel Dice <[email protected]>
* being integration of new API
Signed-off-by: Roman Volosatovs <[email protected]>
* update wasi/src/p3/filesystem to use new stream API
This is totally untested so far; I'll run the tests once we have everything else compiling.
Signed-off-by: Joel Dice <[email protected]>
* update wasi/src/p3/cli to use new stream API
This is totally untested and doesn't even compile yet due to a lifetime issue I don't have time to address yet. I'll follow up later with a fix.
Signed-off-by: Joel Dice <[email protected]>
* fix: remove `'a` bound on `&self`
Signed-off-by: Roman Volosatovs <[email protected]>
* finish `wasi:sockets` adaptation
Signed-off-by: Roman Volosatovs <[email protected]>
* finish `wasi:cli` adaptation
Note, that this removes the read optimization - let's get the implementation complete first and optimize later
Signed-off-by: Roman Volosatovs <[email protected]>
* remove redundant loop in sockets
Signed-off-by: Roman Volosatovs <[email protected]>
* wasi: buffer on 0-length reads
Signed-off-by: Roman Volosatovs <[email protected]>
* finish `wasi:filesystem` adaptation
Signed-off-by: Roman Volosatovs <[email protected]>
* remove `MAX_BUFFER_CAPACITY`
Signed-off-by: Roman Volosatovs <[email protected]>
* refactor `Cursor` usage
Signed-off-by: Roman Volosatovs <[email protected]>
* impl Default for VecBuffer
Signed-off-by: Roman Volosatovs <[email protected]>
* refactor: use consistent import styling
Signed-off-by: Roman Volosatovs <[email protected]>
* feature-gate fs Arc accessors
Signed-off-by: Roman Volosatovs <[email protected]>
* Update test expectations
---------
Signed-off-by: Joel Dice <[email protected]> Signed-off-by: Roman Volosatovs <[email protected]> Co-authored-by: Alex Crichton <[email protected]> Co-authored-by: Roman Volosatovs <[email protected]>
show more ...
|
|
Revision tags: v36.0.2, v36.0.1, v36.0.0 |
|
| #
c42ed27a |
| 12-Aug-2025 |
Alex Crichton <[email protected]> |
Refactor `AbortHandle`, renamed to `JoinHandle` (#11414)
* Refactor `AbortHandle`, renamed to `JoinHandle`
This commit is inspired by recent discussions about providing more guarantees around dropp
Refactor `AbortHandle`, renamed to `JoinHandle` (#11414)
* Refactor `AbortHandle`, renamed to `JoinHandle`
This commit is inspired by recent discussions about providing more guarantees around dropping WASI resources. This commit renames `wasmtime::component::AbortHandle` to `wasmtime::component::JoinHandle` and additionally implements `Future for JoinHandle` to know when the associated task's future has been dropped. The renaming is intended to more closely align with `tokio::task::JoinHandle` where `tokio::task::AbortHandle` is notably different and doesn't have a `Future` implementation. The `Future` implementation helps embedders know exactly when a value has been dropped and synchronize on that.
* Clarify lack of abort-on-drop behavior
show more ...
|
| #
b4475438 |
| 30-Jul-2025 |
Joel Dice <[email protected]> |
refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)
* refactor `{Stream,Future}|{Reader,Writer}` APIs and internals
This makes a several changes to how `{Stream,Future}|{Reader,W
refactor `{Stream,Future}|{Reader,Writer}` APIs and internals (#11325)
* refactor `{Stream,Future}|{Reader,Writer}` APIs and internals
This makes a several changes to how `{Stream,Future}|{Reader,Writer}` work to make 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<u8>` instead of `StreamReader<Vec<u8>>`), 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<Instance>`, 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. In simple cases, it's easy enough to ensure that read and write handles are disposed of properly, but both `wasmtime-wasi` and `wasmtime-wasi-http` have some pretty complicated functions where handles are passed between tasks and/or stored inside resources, so it can be tricky to ensure proper disposal on all code paths. I'm open to ideas for improving this, but I suspect we'll need new Rust 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` such that it would prematurely give up and return a "deadlock" trap error, believing that there was no further work to do, even though the future passed to it was ready to resolve the next time it was polled. I've fixed this by polling it one last 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 to the store; they're unchanged otherwise. Apologies for the diff noise.
Finally, I've tweaked how `wasmtime serve` to poll the guest for content before handing the response to Hyper, which helps performance by ensuring the first content chunk can be sent with the same TCP packet as the beginning of the response.
Signed-off-by: Joel Dice <[email protected]>
fix wasi p3 build and test failures
Signed-off-by: Joel Dice <[email protected]>
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 <[email protected]>
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 dropped
Signed-off-by: Joel Dice <[email protected]>
* lower host stream/future writes in background task
This avoids unsoundness due to guest realloc calls while there are host embedder frames on the stack.
Signed-off-by: Joel Dice <[email protected]>
* fix `tcp.rs` regressions
Signed-off-by: Joel Dice <[email protected]>
---------
Signed-off-by: Joel Dice <[email protected]>
show more ...
|
| #
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 |
|
| #
c34eb3f7 |
| 16-Jul-2025 |
Alex Crichton <[email protected]> |
Require `Accessor` on all future/stream functions (#11250)
* Require `Accessor` on all future/stream functions
This is a follow-up to #11238 which adds `&Accessor` arguments to all functions for fu
Require `Accessor` on all future/stream functions (#11250)
* Require `Accessor` on all future/stream functions
This is a follow-up to #11238 which adds `&Accessor` arguments to all functions for futures and streams. Like #11238 this is done to make future refactorings easier for the internal implementation but the internal implementations are not updated at this time. Many functions, for example, do not use the argument at all just yet. The purpose of this is to ensure host usage of these functions always provides a store context.
This change required large refactorings of the upcoming wasmtime-wasi-http implementation in the wasip3-prototyping repository. That's all been sorted out now though so the changes are being pulled back here into the Wasmtime repository as well.
This commit additionally changes the `watch_*` functions on the various stream/future types to take `&mut self` instead of `self`-by-value. This is mostly a stylistic change and is more API-driven than anything else. Functionally this behaves the same as before where, while watching, the stream/future cannot be read/written to otherwise.
* Review comments
show more ...
|
| #
2b832281 |
| 14-Jul-2025 |
Alex Crichton <[email protected]> |
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 remove
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 which means 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
show more ...
|
| #
fa70f025 |
| 11-Jul-2025 |
Joel Dice <[email protected]> |
implement Component Model async ABI (#11127)
* implement Component Model async ABI
This commit replaces the stub functions and types in `wasmtime::runtime::component::concurrent` and its submodules
implement Component Model async ABI (#11127)
* implement Component Model async ABI
This commit replaces the stub functions and types in `wasmtime::runtime::component::concurrent` and its submodules with the working implementation developed in the `wasip3-prototyping` repo. For ease of review, it does not include any new tests; I'll add those in a follow-up commit.
Note that this builds on #11123; only the most recent commit is new.
Signed-off-by: Joel Dice <[email protected]>
* clear params pointer in `call_async` when future is dropped
This ensures that the closure we pass to `prepare_call` will never see a stale pointer.
Note that this could potentially be made more efficient; I'm starting with a simple solution, and we can refine from there.
Signed-off-by: Joel Dice <[email protected]>
* Remove unsafety from accessing concurrent async state
* Remove a dead variant when async is disabled
* Add tests for `tls.rs` unsafe code
* Refactor `AbortHandle`
* Don't close over the entire future in the `AbortHandle`, instead change it to just the bare minimum state to manage aborts. * Move aborting logic into a helper `AbortHandle::run` function which handles the is-this-aborted-check internally. * Refactor some logic around spawns how `AbortHandle` is managed/created.
* Internalize some functions/types
* add FIXME comment to `states.rs`
Signed-off-by: Joel Dice <[email protected]>
* reference issue 11190 in `table.rs` TODO
Signed-off-by: Joel Dice <[email protected]>
* switch `use` directives to conventional syntax
Signed-off-by: Joel Dice <[email protected]>
* remove redundant accessor methods
Signed-off-by: Joel Dice <[email protected]>
* reference issue 11191 in `yield` TODO comments
Signed-off-by: Joel Dice <[email protected]>
* replace `dummy_waker` with `Waker::noop`
Signed-off-by: Joel Dice <[email protected]>
* remove obsolete `AsyncState::spawned_tasks` field
Signed-off-by: Joel Dice <[email protected]>
* only call post-return automatically for `call_concurrent`
This restores the original behavior of requiring explicit post-return calls for `call[_async]` invocations.
Signed-off-by: Joel Dice <[email protected]>
* Favor function arguments before closures
* Simplify `watch` a bit
Mostly move unnecessary state out of the `Arc`.
* fix task handle leaks and add test coverage
We weren't always disposing of guest or host task handles once they became unreachable. This adds a couple of hidden methods which integration tests may use to guard against use-after-delete, double-delete, and leak bugs regarding waitable handles. It also tightens up handle management in `concurrent.rs` to ensure those tests pass.
Signed-off-by: Joel Dice <[email protected]>
* Encapsulate type erasure in stream buffers
Don't rely on all buffers to handle `TypeId` and assertions and such, instead have a helper type which is the one location of the assertions and everything else can stay typed.
* Remove some methods ending in underscores
* Refactor unsafety in `buffers.rs`
Mostly move away from raw pointers and instead use utilities like `&[MaybeUninit<T>]`. Also make `WriteBuffer` an `unsafe` trait after absorbing the `TakeBuffer` trait. Update all safety-related comments here and there too.
* remove task on drop in `TypedFunc::call_async`
This avoids the need for an `Arc`.
Signed-off-by: Joel Dice <[email protected]>
* remove obsolete clause from `FutureReader::read` docs
Signed-off-by: Joel Dice <[email protected]>
* unhide and expand docs for `WriteBuffer` and `ReadBuffer`
Signed-off-by: Joel Dice <[email protected]>
* add optional `component-model-async-bytes` feature
This gates interop with the `bytes` crate, making it optional and non-default.
Signed-off-by: Joel Dice <[email protected]>
---------
Signed-off-by: Joel Dice <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
show more ...
|
| #
838ed2d0 |
| 07-Jul-2025 |
Alex Crichton <[email protected]> |
Enable `allow_attributes_without_reason` (#11195)
* Enable `allow_attributes_without_reason`
This commit enables the `clippy::allow_attributes_without_reason` for the `wasmtime` crate which previou
Enable `allow_attributes_without_reason` (#11195)
* Enable `allow_attributes_without_reason`
This commit enables the `clippy::allow_attributes_without_reason` for the `wasmtime` crate which previously forcibly allowed it. The reason this was allowed was that when the workspace was first migrated the Wasmtime crate had too many instances that I was willing to fix. I've now come back around and tried to fix everything.
In short: ideally delete `#[allow]`, otherwise use `#[expect]`, otherwise use `#[allow]`.
prtest:full
* Adjust some directives
* Fix some warnings
* Fix stack switching size tests on unix
* Don't have a conditional `Drop` impl
* Force `testing_freelist` method to be used
Too lazy to write `#[cfg]`, but not too lazy to write a test.
show more ...
|
| #
b221fca7 |
| 03-Jul-2025 |
Joel Dice <[email protected]> |
update `component-model-async` plumbing (#11123)
* [DO NOT MERGE] update `component-model-async` plumbing
This pulls in the latest Component Model async ABI code from the `wasip3-prototyping` repo,
update `component-model-async` plumbing (#11123)
* [DO NOT MERGE] update `component-model-async` plumbing
This pulls in the latest Component Model async ABI code from the `wasip3-prototyping` repo, including various API refactors and spec updates.
This includes all the changes to the `wasmtime` crate from `wasip3-prototyping` _except_ that the `concurrent` submodule and child submodules contain only non-functional stubs. For that reason, and the fact that e.g. `Func::call_async` is now implemented in terms of `Func::call_concurrent`, most of the component model tests are failing. This commit is not meant to be merged as-is; a follow-up commit (to be PR'd separately) will contain the real `concurrent` implementation, at which point the tests will pass again. I'm splitting these into separate PRs to make review easier.
Signed-off-by: Joel Dice <[email protected]>
* Undo wit-bindgen changes
No longer necessary after other refactors
* Move back to crates.io-based wit-bindgen
* Undo upgrade of http-body-util
(deferred for future PR)
* Add back in arbitrary use of async
Looks like it may have been lost by accident
* Make imports more conventional for Wasmtime
* Some minor changes
* Privatize a component field
* Cut down a bit on #[cfg]
* Undo a no-longer-necessary `pub`
* add doc comments for `{Future,Stream,ErrorContext}Any`
Signed-off-by: Joel Dice <[email protected]>
* rename `concurrent` stub module to `concurrent_disabled`
...and avoid panicking in the stubs.
Signed-off-by: Joel Dice <[email protected]>
* fix test regression
Signed-off-by: Joel Dice <[email protected]>
* revert `call_async` and `post_return_impl` changes
These will need to wait until the `component-model-async` feature is fully implemented.
Signed-off-by: Joel Dice <[email protected]>
* remove unused struct
Signed-off-by: Joel Dice <[email protected]>
* add `Options::callback` field
This isn't used yet, but will be used when the real `component-model-async` implementation is merged.
Signed-off-by: Joel Dice <[email protected]>
* Remove no-longer-needed feature
* Trim reexports from Wasmtime
Some of these are no longer needed or can be avoided with small changes. Some deps are likely needed in the next commit but they'll be best added there.
* Update test expectations
* More trimming of Cargo.toml
* Defer `*Buffer` traits to next PR
Not needed for this PR I believe.
* Use conventional Wasmtime imports + remove dummy_waker
* Reduce duplication in `*_disabled`
* Remove some unncessary bounds
* Remove some `for<'a>` bounds where unnecessary
* Remove another bound
* Defer more functions to the next PR
`drop_fibers` is different in the next PR, so defer it to then.
* Remove some reexports no longer necessary
Bindings generation changed awhile back so these aren't needed, defer the implementations to the next PR.
* Remove unnecessary drop
This was already moved to `run_manual_drop_routines`
* Defer a `pub(crate)` to a future PR
* Expand comments in traphandlers
* Defer some types to the next PR
* Update linker documentation
* Add `Send`/`Sync` bounds to `ComponentType`
This commit is extracted from from review of #11123 and #11127. While not literally present in those PRs it's my own personal conclusion that it's best to just go ahead and add these bounds at the "base" of the component trait hierarchy. The current implementation in #11123 adds bounds in many locations and this would remove the need to add bounds everywhere and instead have everything inherited through the `Lift` and `Lower` traits.
This raises the question of: why? The main conclusion that I've reached leading to this change is that Wasmtime currently will store `R`, a return value, on the stack during the lowering process back into linear memory. This might involve allocation, however, meaning that wasm can be invoked and a context switch could happen. For Wasmtime's `unsafe impl` of `Send` and `Sync` on fibers to be sound it requires that this stack-local variable is also `Send` and `Sync` as it's an entirely user-provided type. Thus I've concluded that for results it's always required for these to be both `Send` and `Sync` (or at the very least, `Send`).
Given that I've gone ahead and updated to require both `Send` and `Sync` for both params and results. This is not expected to actually have any impact in practice since all primitives are already `Send`/`Sync` (minus `Rc` impls all removed here) and all `bindgen!`-generated types are compositions of `Send`/`Sync` primitives meaning that they're also `Send` and `Sync`.
* Remove some now-unnecessary bounds
* Fix build after #11160
* Remove some now-unnecessary duplicate bounds
* Uncomment test that now works
* Undo accidental doc wrap
* Clarify comment on `Value` types
Don't leave `TODO` in public-facing documentation ideally
* Actually resolve the conflict (forgot to commit)
* Avoid returning boxed futures in APIs
* Defer making constructors more public to a future PR
* Make a method name more conventional
* Refactor `linear_lift_into_from_memory`
* Drop the `max_count` parameter in favor of slicing the `WasmList` itself. Avoids situations such as what happens if `max_count` is larger than the length of the list. * Don't have the default implementation collect to a vector and then push all that onto a different vector. Instead push each item individually through `extend`.
* De-indent a block of code added
* Remove unsafety from `prepare_call`
Mostly move the parameters themselves to the closure to avoid raw pointers/drop/etc.
This will have the consequence of in the future `call_async` is going to now require `Params: 'static` but that seems more-or-less inevitable at this point.
* Go back to returning box, alas.
* Apply same treatment to lift function
Make it a closure and reduce some levels of indirection of the various functions in play.
* Refactor `lower_params` to require less context.
Relax the bounds on the closure specified since it's immediately called and then additionally take out parameters/captures that the closure can carry itself.
* Don't pass extraneous `Instance` parameter
This can now be inferred from `Func`.
* Clean up some SAFETY comments
* Generalize the signature of `lift_results`
* Move `lift_results` function to `Func`
Also rename the lift/lower helpers to `with_{lift,lower}_context`
* Remove parameter from `with_lift_context`
Like `with_lower_context` this is fine to capture in the closure passed in.
* Simplify the dynamic lifting logic
Don't call `with_lift_context` in two locations, only call it once with a dynamic parameter.
* Refactor away the `Func::lift_results_sync` helper
* Use `with_lift_context` in `call_raw`
* Simplify a call to `Func::call_unchecked_raw`
* Ungate `with_lift_context` to fix non-cm-async build
* Fix compile (bad cherry-pick conflict resolution)
* Use `with_lower_context` in `call_raw`
Trying to unify the async/concurrent paths as much as possible.
* Move params out of `call_raw`
Let closures capture the params, no need to thread it through as an unnecessary argument.
* Clean up unsafety in `Func::call_raw`
* Accurately mark `call_raw` itself as `unsafe`, then document why callers should be safe. * Don't have one large `unsafe` block in `call_raw`, instead split it up with separate safety comments.
* Move a one-off type definition closer to its use
* Avoid intermediate allocations in dynamic calls
* Simplify a future-return site
* Deduplicate checking parameter count
* Simplify a future invocation with `?`
* Simplify a variable declaration
* Simplify some function signatures
* Remove outdated safety comment
* Refactor to not require `Params: 'static` on `call_async`
* Remove no-longer-necessary SAFETY comment
* Fix typos
* Add a fast-path with no `Box` for sync host functions
Speeds up host calls by ~20% and puts them back on parity with the beforehand numbers Wasmtime has.
* Synchronize signatures of async/concurrent dynamic calls
Use slices for both instead of vecs for one and slices for the other. Required some slight rejiggering. Apparently one can solve a closure problem with another closure, then one surely has no more closure problems.
* Fix non-cm-async build
---------
Signed-off-by: Joel Dice <[email protected]> Co-authored-by: Alex Crichton <[email protected]>
show more ...
|
|
Revision tags: v34.0.1, v33.0.1, v24.0.3, v32.0.1, v34.0.0 |
|
| #
beca86b0 |
| 09-Jun-2025 |
Alex Crichton <[email protected]> |
Re-enable concurrent bindings generation tests (#10972)
* Re-enable concurrent bindings generation tests
This commit re-enables tests for bindings generation for concurrent calls in the main repo
Re-enable concurrent bindings generation tests (#10972)
* Re-enable concurrent bindings generation tests
This commit re-enables tests for bindings generation for concurrent calls in the main repo after all syncs have now finished with wasip3. This additionally adds some skeleton APIs that the bindings generator uses which are necessary to get tests passing.
* Update test expectations
show more ...
|
| #
8fb9d189 |
| 03-Jun-2025 |
Alex Crichton <[email protected]> |
Remove `Stored` usage from `wasmtime::component::Instance` (#10913)
* Remove mutability required on a number of component methods
Powered by previous refactorings it's possible to just take `&Store
Remove `Stored` usage from `wasmtime::component::Instance` (#10913)
* Remove mutability required on a number of component methods
Powered by previous refactorings it's possible to just take `&StoreOpaque` in these locations.
* Move core instance map into `ComponentInstance`
This commit moves the mapping from a `RuntimeInstanceIndex` to a `wasmtime::Instance` from `wasmtime::component::InstanceData` into the internal `ComponentInstance` structure. This is done in preparation to remove `InstanceData` eventually.
* Move `Component` to live in `ComponentInstance`
Previously this lived in `InstanceData` but that's just a historical artifact of the old `wasmtime` and `wasmtime-runtime` split. Nowadays it's possible to store `Component` directly to further move information out of `InstanceData`.
* Move `InstanceData::imports` to `ComponentInstance`
More preparation for the removal of `InstanceData` entirely.
* Move lookup functions from `InstanceData` to `ComponentInstance`
More prep for the removal of `InstanceData`.
* Reduce some more reliance on `InstanceState`
Just removing it from some type signatures to make future removal easier.
* Remove an unused result from a helper function
No caller needs it, so go ahead and remove it.
* Make `ComponentInstance::imports` private
This moves some methods around and documents preexisting `unsafe` contracts to get this field private and prevent external access to it.
* Remove `InstanceData` from `Instantiator`.
Use `OwnedComponentInstance` instead.
* Remove `InstanceData`, refactor `Instance`
This commit refactors the representation of `component::Instance` to be purely index-based to data already within a store. This makes creation of an `Instance` free compared to before where auxiliary data needed to be created. Note that this doesn't actually change storage within a `Store<T>` as instances are still there, it's just that now the storage lives in a non-`Stored`-related location.
show more ...
|