Fix the current guest task when calling `realloc` (#12718)

* Fix the current guest task when calling `realloc`

This commit fixes some fallout from #12550 where after that PR the
current task regist

Fix the current guest task when calling `realloc` (#12718)

* Fix the current guest task when calling `realloc`

This commit fixes some fallout from #12550 where after that PR the
current task registered when a guest's `realloc` was called was
incorrect. This additionally fixes issues where guest-to-guest
trampolines also had the wrong task registered when `realloc` was being
called. Finally this adjusts a few locations that "no borrows should be
active" traps happen to ensure that it happens around the time of when a
task returns rather than after the lowering of its values happens.

* Fix non-async build

show more ...

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are c

Relax panics in async/futures to traps/errors (#12688)

* Relax panics in async/futures to traps/errors

This commit is an admittance that I don't believe we're going to get
to a point where we are confident enough in the fuzzing of
component-model-async such that we could confidently say we're
exercising the vast majority of possible panics. Development of
component-model-async has shown a steady trickle of panics over the
course of the development of the feature, and this trend has been
persistent over time as well.

An attempt was made in #12119 to add a fuzzer dedicated to async events
but that didn't actually find anything in development and it has missed
a number of panics present before and discovered after its introduction.
Overall I do not know how to improve the fuzzer to the point that it
would find pretty much all of the existing async-related panics over
time.

To help address this concern of the `concurrent.rs` implementation this
commit goes through and replaces things like `unwrap()`, `assert!`,
`panic!`, and `unreachable!` with an error-producing form. The benefit
of this is that a bug in the implementation is less likely to result in
a panic and instead just results in a non-spec-compliant trap. The
downside of doing this though is that it can become unclear what errors
are "first class traps", or expected to be guest reachable, and which
are expected to be bugs in Wasmtime. To help address this I've performed
a few refactorings here as well.

* Some traps previously present as error strings are now promoted to
using `Trap::Foo` instead. This has some refactoring of the Rust/C
side as well to make it easier to define new variants. Tests were
additionally added for any trap messages that weren't previously
tested as being reachable.

* A new `bail_bug!` macro was added (internally) for Wasmtime. This is
coupled with a concrete `WasmtimeBug` error type (exported as
`wasmtime::WasmtimeBug`). The intention is that `bail!` continues to
be "here's a string and I'm a bit too lazy to make a concrete error"
while `bail_bug!` indicates "this is a bug in wasmtime please report
this if you see it".

The rough vision is that if an error condition is reached, and the system
is not broken in such a way that panicking is required, then `bail_bug!`
can be used to indicate a bug in Wasmtime as opposed to panicking. This
reduces the real-world impact of hitting these scenarios by downgrading a
CVE-worthy `panic!` into a bug-worthy non-spec-compliant trap. Not all
panics are able to be transitioned to this as some are load bearing from
a safety perspective or similar (or indicate something equally broken),
but the vast majority of cases are suitable for "return a trap, lock
down the store, and let destructors take care of everything else".

This change additionally has resulted in API changes for `FutureReader`
and `StreamReader`. For example creation of these types now returns a
`Result` for when the `ResourceTable` is full, for example, instead of
panicking.

* Fix CI build

* Translate `WasmtimeBug` to panics in debug mode

* Review comments

* Refactor some stream methods for fewer panics

show more ...

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 ...

Refactor borrow state tracking for async tasks (#12550)

* Refactor borrow state tracking for async tasks

This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for b

Refactor borrow state tracking for async tasks (#12550)

* Refactor borrow state tracking for async tasks

This commit is a somewhat deep refactoring of how the state of
`borrow<T>` is managed for both the host and the guest with respect to
async tasks. This additionally refactors how some async task management
is done for host-called functions.

The fundamental problem being tackled here is #12510. In that issue it
was discovered that the way `CallContext`, the borrow tracking mechanism
in Wasmtime, is managed is incompatible with async tasks. Specifically
the previous assumption of the scope being mutated for a borrow is
somewhere on the call stack is no longer true. It's possible for an
async task to be suspended, for example, and then a sibling task drops a
borrow which should update the scope of the suspended task. There were a
number of other small issues I noticed here and there which this PR
additionally has tests for, all of which failed before this change and
pass afterwards.

The manner in which borrow state is manipulated is a pretty old part of
the component model implementation dating back to the original
implementation of resources. I decided to forgo any possible quick fix
and have attempted to more deeply refactor and integrate async tasks
into all of this infrastructure. A list of the changes made here are:

* The `CallContexts` structure, a stack of `CallContext`, was removed.
Tasks now directly store a `CallContext` which is the source of truth
for borrow tracking for that call, and it does not move from this
location. The store `CallContexts` is now deleted in favor of updating
the `Option<ConcurrentState>` in the store to be an `enum` of either
concurrent state or a stack. In this manner the old stack-based
structure is still used sometimes, but it's impossible to reach when
concurrency is enabled.

* Entry to the host from guests now reliably pushes a `HostTask` into
the store. Previously where a frame were always pushed into a
`CallContext` a `HostTask` is pushed into the store. This is still
expected to be a bit too expensive for cheap host calls, but it
doesn't meaningfully change the performance profile of before.

* The `resource_enter_call` and `resource_exit_call` libcalls have been
removed. These are now folded into the `enter_sync_call` and
`exit_sync_call` libcalls. Emission of these hooks has been updated
accordingly. The concept of entering a call more generally has been
removed. This is more formally known in the async world as a task
starting, so the task creation is now responsible for the demarcation
of entering a call. Additionally this means that the concept of
exiting a call has somewhat gone away. Instead this method was renamed
to `validate_scope_exit` which double-checks that a borrow-scope can
be exited but doesn't actually remove the task. Task removal is
deferred to preexisting mechanisms.

* Management of a `GuestTask`'s previous `Option<CallContext>` field,
for example taking/restoring and pushing/popping onto `CallContexts`
is now all gone. All related code is outright deleted as the
`GuestTask`'s now non-optional `CallContext` field is the source of truth.

* The `ConcurrentState` structure now stores a `CurrentThread` enum
instead of `Option<QualifiedThreadId>`. This represents how the
currently executing thread could be a host thread, not just a guest
thread, which is required for borrow-tracking.

* `HostTask` creation in `poll_and_block` and `first_poll`, the two main
entrypoints of async host tasks when called by the guest, is now
externalized from these functions. Instead these functions assume that
the currently running thread is already a `HostTask` of some kind.

* In `poll_and_block` the host's result is no longer stored in the guest
task but in the host task instead.

Overall this enables the `*.wast` test for #12510 to fix the original
issue. This then adds new tests to ensure that cleanup of various
constructs happens appropriately, such as cancelling a host task should
clean up its associated resources. Additionally synchronously calling an
async host task no longer leaks resources in a `Store` and should
properly clean up everything.

There is still more work to do in this area (e.g. #12544) but that's
going to be deferred to a future PR at this point.

Closes #12510

prtest:full

* Review comments/CI fixes

show more ...

Delete an unused field in `GuestTask` (#12545)

Looks like there are no more users of this field, so no need to persist
it.

Move `ResourceTables` constructors to `StoreOpaque` (#12546)

* Move `ResourceTables` constructors to `StoreOpaque`

This is intended to consolidate where they're constructed, provide
access to the h

Move `ResourceTables` constructors to `StoreOpaque` (#12546)

* Move `ResourceTables` constructors to `StoreOpaque`

This is intended to consolidate where they're constructed, provide
access to the host data at all times, and pave the way for a future
refactoring here to touch fewer lines.

* Fix a cfg

show more ...

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

* deprecate `[Typed]Func::post_return[_async]` and make them no-ops

With the advent of the Component Model concurrency ABI

deprecate `[Typed]Func::post_return[_async]` and make them no-ops (#12498)

* deprecate `[Typed]Func::post_return[_async]` and make them no-ops

With the advent of the Component Model concurrency ABI and it's `task.return`
intrinsic, post-return functions have been informally deprecated and are
expected to be removed for WASI 1.0 and the corresponding stable edition of the
Component Model. Consequently, it does not make sense anymore to require
embedders to explicitly call the post-return function after using
`[Typed]Func::call[_async]`.

As of this commit, `[Typed]Func::post_return[_async]` are no-ops. Instead, the
post-return function is called automatically as part of
`[Typed]Func::call[_async]` if present, which is how
`[Typed]Func::call_concurrent` has worked all along. In addition, this commit
fixes and tests a couple of cases where the task and/or thread was being
disposed of before the post-return function was called.

* address review feedback

* test post-return function in more scenarios

Specifically, I've split the `invoke_post_return` test into multiple tests:

- using `TypedFunc::call`
- using `TypedFunc::call_async` with concurrency support enabled
- using `TypedFunc::call_async` with concurrency support disabled
- using `Func::call_async` with concurrency support disabled
- using `TypedFunc::call_concurrent`

* remove GCC/clang-specific deprecation attribute

This broke the MSVC build.

* bless bindgen output

* remove obsolete post-return functions and fields

Now that post-return calls are handled internally without requiring explicit
action by the embedder, we can avoid unnecessary bookkeeping.

show more ...

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our fl

Forbid rustdoc warnings in CI (#12420)

* Forbid rustdoc warnings in CI

This commit corrects our handling of rustdoc flags in CI to ensure that
warnings indeed fire. Additionally this changes our flags to pass
`-Dwarnings` to ensure that we have warning-free doc builds when all
features are enabled at least.

There were quite a lot of preexisting issues to fix, so this
additionally goes through and fixes all the warnings that cropped up.

* Update nightly toolchain again

prtest:full

* Update another nightly

* Fix a warning in generated code

show more ...

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 ...

consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or

consistently create thread and task when entering component instance (#12379)

* consistently create thread and task when entering component instance

Previously, we weren't creating a new thread or task in all cases when entering
a component instance, even when component model async features were enabled. In
particular, entering an instance via a sync-to-sync, guest-to-guest adapter, via
`Linker::instantiate[_async]`, or via `[Typed]Func::call` all skipped creating a
thread or task, creating panics and/or instance mismatches in certain cases.

This commit addresses all those cases and also adds assertions to all CM async
intrinsics to verify that the caller instance matches the most-recently-pushed
task. Note that we still skip pushing and popping threads and tasks if no CM
async features are enabled in the `Config`.

In order to populate the `GuestTask::instance` field for tasks created as part
of `Linker::instantiate[_async]` calls, I had to add a
`RuntimeComponentInstanceIndex` field to `GlobalInitializer::InstantiateModule`
and friends so it would be available when needed.

While testing this, I uncovered and fixed a couple of related issues:

- We weren't checking the `may_leave` flag when guest-to-guest calling a resource destructor
- We weren't checking whether a subtask was ready to delete (e.g. that no threads were still running) before attempting to delete it while deleting its supertask

* fix warnings when component-model-async feature disabled

* address review feedback

* push a task when calling a resource dtor host-to-guest

* add tests which call `thread.index` from realloc and post-return functions

...and assert that the indexes match as expected.

Getting the post-return test to pass required moving the call to
`StoreOpaque::exit_sync_call` to after the post-return function is called.

show more ...

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 ...

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 ...

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 ...

Update Func & TypedFunc's doc comments to explain Accessor and Store::run_concurrent (#12330)

* docs: explain Accessor and run_concurrent

* Update crates/wasmtime/src/runtime/component/func/typed.

Update Func & TypedFunc's doc comments to explain Accessor and Store::run_concurrent (#12330)

* docs: explain Accessor and run_concurrent

* Update crates/wasmtime/src/runtime/component/func/typed.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

* Update crates/wasmtime/src/runtime/component/func/typed.rs

Co-authored-by: Nick Fitzgerald <[email protected]>

* chore: update comment formatting

* chore: show func getter

---------

Co-authored-by: Nick Fitzgerald <[email protected]>

show more ...

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 ...

allow recursive Wasm invocation from concurrent host functions (#12152)

* allow recursive Wasm invocation from concurrent host functions

The core changes here are:

- remove an unnecessary assertio

allow recursive Wasm invocation from concurrent host functions (#12152)

* allow recursive Wasm invocation from concurrent host functions

The core changes here are:

- remove an unnecessary assertion from `concurrent::prepare_call`
- track instance states (e.g. backpressure, etc.) on a per `(Instance, RuntimeComponentInstanceIndex)` basis
- both parts of that key are needed now that concurrent state is tracked on a per-store basis rather than a per-instance basis since `RuntimeComponentInstanceIndex`es are not globally unique

While discussing the above with Alex, we realized the use of a `HashMap` to
track per-instance states was both pessimal and unnecessary. Consequently, I've
folded that state into `ComponentInstance::instance_handle_tables`, renaming it
to `instance_states`. That involved a fair amount of code churn, but doesn't
change behavior except as described in the second bullet point above.

Thanks to Alex for the test case!

Fixes #12098

Co-authored-by: Alex Crichton <[email protected]>
Signed-off-by: Joel Dice <[email protected]>

* use new `RuntimeInstance` type instead of tuples

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>
Co-authored-by: Alex Crichton <[email protected]>

show more ...

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 ...

Cooperative Multithreading (#11751)

* Initial work

* Almost compiling

* Partially working

* Cleanup

* Fix merge

* Cancellation and suspension refactoring

* Remove printlns

* Test with several

Cooperative Multithreading (#11751)

* Initial work

* Almost compiling

* Partially working

* Cleanup

* Fix merge

* Cancellation and suspension refactoring

* Remove printlns

* Test with several threads

* More testing

* Cancellation

* Fix cancellation for explicit suspends

* Finish cancellation test

* Store threads in the instance table

* Deletion almost there

* Tests all pass

* Tighten up task deletion

* Set thread state correctly

* Store pairs of thread and task ids

* Remove lift abi members

* Cleanup unnecessary change

* More cleanup

* Cleanup

* Revert cargo changes

* Revert cargo changes

* Comments

* Comments on test

* Update comments

* Update comments

* Add space that was removed in an earlier commit

* Cleanup

* Delete threads from the instance table

* Revert cargo file

* Remove dead code

* Clippy changes

* Clippy

* Revert unnecessary changes

* Revert unnecessary changes

* Revert unnecessary changes

* Revert unnecessary changes

* Revert unnecessary changes

* Review comments

* Review feedback

* Make thread IDs per-component-instance

* Fix config

* Tighten up completion

* Clippy

* Trigger full PR test

* Move funcref table reading

* Remove unused import

* Formatting

* Rename RemoveOnDrop

* Review feedback

* Review feedback

* Move start thread closure

* Review feedback

* Review feedback

* Correct feature for import

* Review feedback

* Disable failing tests

* Enable fixed tests

* Review feedback

* Readd tests

* Ignore task deletion test with Miri

show more ...

Add first-class type access of `component::Func` (#11943)

When `Func:::{params,results}` was added we didn't have
`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it's
cheaper and

Add first-class type access of `component::Func` (#11943)

When `Func:::{params,results}` was added we didn't have
`types::ComponentFunc` at the time. Now that `ComponentFunc` exists it's
cheaper and easier to access and work with that instead of the one-off
accessors on `Func`.

show more ...

Document some known async pitfalls (#11871)

* Document some known async pitfalls

* `call_concurrent` is more like a "spawn" operation within a store so
it cannot be cancelled by dropping the retu

Document some known async pitfalls (#11871)

* Document some known async pitfalls

* `call_concurrent` is more like a "spawn" operation within a store so
it cannot be cancelled by dropping the returned future.
* `call_concurrent` cannot be cancelled today other than by dropping the
whole store. This is the subject of #11833.
* `call_concurrent` cannot make progress outside of `run_concurrent`.
* `run_concurrent` does not properly implement "select" operations
internally due to #11869 and #11870. This means that timeouts within
`run_concurrent` will not work.

* Review comments

show more ...

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

* move `ConcurrentState` from `ComponentInstance` to `Store`

This has a few benefits:

- No need to specify an instance when crea

move `ConcurrentState` from `ComponentInstance` to `Store` (#11796)

* move `ConcurrentState` from `ComponentInstance` to `Store`

This has a few benefits:

- No need to specify an instance when creating or piping from a stream or future.
- No need to track the instance in an `Accessor`.
- You may now execute tasks for multiple instances in a single event loop.

The main drawback is that, if one of several instances within a single store
traps, it effectively means all instances have trapped, and the store can't be
used to create new instances. The way to avoid that is to use separate stores
for instances which must be isolated from others.

As a result of this change, a lot of code had to move from e.g. `impl Instance`
to e.g. `impl StoreOpaque`, so the diff is pretty huge, but the changes
themselves are almost entirely non-functional.

Fixes #11226

Signed-off-by: Joel Dice <[email protected]>

* fix non-component-model-async build

Signed-off-by: Joel Dice <[email protected]>

* fix outdated doc comment

Signed-off-by: Joel Dice <[email protected]>

* address review feedback

- restore `ComponentStoreData` encapsulation
- avoid conditional code duplication in `LiftContext::new`

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

don't trap on idle in `Instance::run_concurrent` (#11756)

Previously, `Instance::run_concurrent` returned `Trap::AsyncDeadlock` when all
guest tasks and background host tasks had completed, and yet

don't trap on idle in `Instance::run_concurrent` (#11756)

Previously, `Instance::run_concurrent` returned `Trap::AsyncDeadlock` when all
guest tasks and background host tasks had completed, and yet the future
parameter it was passed still hadn't resolved. The theory was that this
indicated a mistake on the host embedder's part, but it turns out there are
scenarios where this is actually what the embedder wanted.

For example, consider a host embedder that implements a pool of worker tasks,
each of which runs a loop inside async closure passed to
`Instance::run_concurrent`. In this case, each worker accepts jobs (which
involve calling guest functions) from a multiple-producer, multiple-consumer job
queue, adding them to a `futures::stream::FuturesUnordered` so they can be run
concurrently. When all the jobs accepted by a given worker have finished, there
may be a lull during which no new jobs are yet available. In that case, the
worker _could_ break out of the loop, resolve the future, allow
`Instance::run_concurrent` to finish, and wait until the next job arrives before
calling `Instance::run_concurrent` again, but that's more awkward (i.e. nested
loops, complicated control flow) than just a single loop inside
`Instance::run_concurrent` that goes idle now and then.

In short, the closure passed to `Instance::run_concurrent` might experience
delays between when a set of guest tasks have completed and when the next set
are ready to start, and that's not necessarily a bug.

Internally, I've added a new `run_concurrent_trap_on_idle` function, which
provides the original, trapping behavior, and I'm using it to implement
`[Typed]Func::call_async`, in which case it _is_ an error if the event loop goes
idle without the future resolving. If this turns out to be useful as part of
the public API, we can change the `pub(super)` to `pub`.

Signed-off-by: Joel Dice <[email protected]>

show more ...

disallow exiting a component instance during a post-return call (#11688)

* disallow exiting a component instance during a post-return call

This is a relatively recent change to the spec.

In order

disallow exiting a component instance during a post-return call (#11688)

* disallow exiting a component instance during a post-return call

This is a relatively recent change to the spec.

In order to check the `may_leave` flag in all the relevant intrinsics, I had to
plumb the caller `RuntimeComponentInstanceIndex` through a bunch of trampolines
that didn't previously need it, hence the large diff.

Note that I've added a slightly tweaked version of `trap-in-post-return.wast`
and left the upstream version disabled in `test-util/src/wast.rs` due to #11683.

Fixes #11676.

Signed-off-by: Joel Dice <[email protected]>

* fix test regressions

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)

* return `TaskExit` future from `[Typed]Func::call_concurrent`

In addition to returning the value produced by the callee, these

return `TaskExit` future from `[Typed]Func::call_concurrent` (#11662)

* return `TaskExit` future from `[Typed]Func::call_concurrent`

In addition to returning the value produced by the callee, these functions now
also return a `TaskExit` future which resolves once the subtask (and any
transitively-created subtasks) have exited. This partially addresses #11600;
the next step will be to add a `wasmtime-wit-bindgen` option to expose the
`TaskExit` value in generated bindings.

Signed-off-by: Joel Dice <[email protected]>

* address review feedback

`TaskExit` now has an `async fn block` instead of closing over an `impl
AsAccessor` and implementing `Future`.

Signed-off-by: Joel Dice <[email protected]>

---------

Signed-off-by: Joel Dice <[email protected]>

show more ...

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runti

Package component model options in an index (#11324)

* Package component model options in an index

This commit is a refactoring of how canonical ABI options are handled
during compilation and runtime. Previously options were "exploded"
meaning that options were all passed around as parameters but this was a
bummer for a few reasons:

* This is `unsafe`-prone as options have raw pointers such as memory and
functions. This meant that all functions/operations working with
options were fundamentally `unsafe`.

* This was unwieldy as the set of options continues to grow larger over
time. The `VMLoweringCallee` function previously had 10+ parameters,
most of which were canonical ABI options.

To solve these two problems options are now intern'd at compile time to
an `OptionsIndex`, a 32-bit value. This is stored as a new table in
component metadata and consulted at runtime. This means that
`OptionsIndex` can be passed around with an instance for a much safer
means of threading options around. Additionally there's no need to pass
around all parameters individually and instead just one parameter,
`OptionsIndex`, need be threaded through.

This commit additionally overhauls trampoline generation for the
component compiler to avoid a function-per-intrinsic and instead have a
single function that all intrinsics use. I found this easier to
understand and helps codify that all intrinsics are basically the same
with some minor details differing between them.

The end result of this is (hopefully) a net simplification of the
component compiler in addition to a large amount of removal of `unsafe`
code in the async implementation as only safe types are passed around
now instead of raw pointers.

Closes #10143
Closes #11188

* Fill out some TODO comments

show more ...