Wasmtime GitHub notifications bot (Jan 20 2026 at 22:07): Wasmtime GitHub notifications bot (Jan 20 2026 at 22:07):fitzgen opened PR #12377 from fitzgen:concurrent-state-only-when-cm-async to bytecodealliance:main:
Creating the default
ConcurrentStatewill create aFuturesUnorderedwhich will allocate. By making this state optional, we can keep making progress on https://github.com/bytecodealliance/wasmtime/issues/12069, and put off dealing withFuturesUnordereduntil when we are ready to try and make CM async code handle OOMs.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:07):fitzgen requested wasmtime-core-reviewers for a review on PR #12377.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:07):fitzgen requested dicej for a review on PR #12377.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:14):fitzgen updated PR #12377.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:15):dicej created PR review comment:
I'm about to post a PR that adds the following function to
Config:pub(crate) fn enable_component_model_concurrency(&self) -> bool { self.enabled_features.contains(WasmFeatures::CM_ASYNC) || self .enabled_features .contains(WasmFeatures::CM_ASYNC_BUILTINS) || self .enabled_features .contains(WasmFeatures::CM_ASYNC_STACKFUL) || self.enabled_features.contains(WasmFeatures::CM_THREADING) || self .enabled_features .contains(WasmFeatures::CM_ERROR_CONTEXT) }Feel free to pull that into this PR and use it here. I.e. I think we need to check for more than just
CM_ASYNChere, or else enforce that those other features depend on theCM_ASYNCfeature.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:15):dicej submitted PR review.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:52):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:52):fitzgen created PR review comment:
Happy to use that helper (although I'd bikeshed perhaps naming it
cm_concurrency_enabledjust to be less of a mouthful) since it seems like we don't enable transitive features explicitly anymore.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:56):dicej submitted PR review.
Wasmtime GitHub notifications bot (Jan 20 2026 at 22:56):dicej created PR review comment:
Sure, feel free to rename it. Here's the PR, for reference: https://github.com/bytecodealliance/wasmtime/pull/12379. I can rebase that onto whatever you do here.
Wasmtime GitHub notifications bot (Jan 21 2026 at 01:05):github-actions[bot] added the label wasmtime:api on PR #12377.
Wasmtime GitHub notifications bot (Jan 21 2026 at 23:18):fitzgen updated PR #12377.
Wasmtime GitHub notifications bot (Jan 21 2026 at 23:28):fitzgen updated PR #12377.
Wasmtime GitHub notifications bot (Jan 21 2026 at 23:31):fitzgen commented on PR #12377:
So I got things working, but I had to effectively turn
cfg(feature = "component-model-async")from being a static, compile-time only feature to also being a dynamic, run-time feature. @alexcrichton you probably have opinions here.
Wasmtime GitHub notifications bot (Jan 21 2026 at 23:37):fitzgen updated PR #12377.
Wasmtime GitHub notifications bot (Jan 22 2026 at 01:05):github-actions[bot] added the label wasmtime:config on PR #12377.
Wasmtime GitHub notifications bot (Jan 22 2026 at 02:31):github-actions[bot] commented on PR #12377:
Label Messager: wasmtime:config
It looks like you are changing Wasmtime's configuration options. Make sure to
complete this check list:
[ ] If you added a new
Configmethod, you wrote extensive documentation for
it.<details>
Our documentation should be of the following form:
```text
Short, simple summary sentence.More details. These details can be multiple paragraphs. There should be
information about not just the method, but its parameters and results as
well.Is this method fallible? If so, when can it return an error?
Can this method panic? If so, when does it panic?
Example
Optional example here.
```</details>
[ ] If you added a new
Configmethod, or modified an existing one, you
ensured that this configuration is exercised by the fuzz targets.<details>
For example, if you expose a new strategy for allocating the next instance
slot inside the pooling allocator, you should ensure that at least one of our
fuzz targets exercises that new strategy.Often, all that is required of you is to ensure that there is a knob for this
configuration option in [wasmtime_fuzzing::Config][fuzzing-config] (or one
of its nestedstructs).Rarely, this may require authoring a new fuzz target to specifically test this
configuration. See [our docs on fuzzing][fuzzing-docs] for more details.</details>
[ ] If you are enabling a configuration option by default, make sure that it
has been fuzzed for at least two weeks before turning it on by default.[fuzzing-config]: https://github.com/bytecodealliance/wasmtime/blob/ca0e8d0a1d8cefc0496dba2f77a670571d8fdcab/crates/fuzzing/src/generators.rs#L182-L194
[fuzzing-docs]: https://docs.wasmtime.dev/contributing-fuzzing.html
<details>
To modify this label's message, edit the <code>.github/label-messager/wasmtime-config.md</code> file.
To add new label messages or remove existing label messages, edit the
<code>.github/label-messager.json</code> configuration file.</details>
Wasmtime GitHub notifications bot (Jan 22 2026 at 15:51):dicej submitted PR review:
LGTM, thanks.
Regarding the WAST test failures: now that the component model combines resource, task, thread, future, stream, and error-context handles all into a single table, tests involving those handles can be sensitive to whether or not e.g. a thread handle has been implicitly allocated as part of a call. For example, the first resource handle created by a guest will have a value of 1 if a thread handle was _not_ allocated (i.e. because CM concurrency is disabled), but it will have a value of 2 if a thread handle _was_ allocated. Also, Wasmtime makes the distinction between "not a valid handle at all" and "a valid handle, but not of the expected kind (e.g. a thread handle being used as a resource handle)".
I made this update as part of https://github.com/bytecodealliance/wasmtime/pull/12379; I suspect we'll need to do the same here. In some cases, that might mean explicitly enabling CM async for a given WAST (assuming it's been written with the assumption that a thread handle is allocated for each guest call). In other cases, it might mean changing the expected trap message and/or expected handle values. I can tackle that, if you'd like.
Wasmtime GitHub notifications bot (Jan 22 2026 at 16:44):fitzgen updated PR #12377.
Wasmtime GitHub notifications bot (Jan 22 2026 at 16:45):fitzgen commented on PR #12377:
Thanks! Flagging the two offending wast tests as requiring CM async was straightforward and resolved the issues
Wasmtime GitHub notifications bot (Jan 22 2026 at 17:56):fitzgen added PR #12377 Only create ConcurrentState in a Store when CM async is enabled to the merge queue.
Wasmtime GitHub notifications bot (Jan 22 2026 at 18:25):fitzgen merged PR #12377.
Wasmtime GitHub notifications bot (Jan 22 2026 at 18:25):fitzgen removed PR #12377 Only create ConcurrentState in a Store when CM async is enabled from the merge queue.
Wasmtime GitHub notifications bot (Jan 22 2026 at 19:23):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jan 22 2026 at 19:23):alexcrichton created PR review comment:
How come this was enabled? For debugging, or intentional?
As an unstable feature this is something I'd ideally like to keep turned off until component-model-async is ready
Wasmtime GitHub notifications bot (Jan 22 2026 at 19:37):fitzgen submitted PR review.
Wasmtime GitHub notifications bot (Jan 22 2026 at 19:37):fitzgen created PR review comment:
wasmtime serveandwasi-httpunconditionally use the concurrency machinery today. We don't have a separate switch for the internal concurrency machinery vs the Wasm-facing component model async feature. Probably we need something likeGC_TYPES, I suppose.
Wasmtime GitHub notifications bot (Jan 23 2026 at 17:34):alexcrichton submitted PR review.
Wasmtime GitHub notifications bot (Jan 23 2026 at 17:34):alexcrichton created PR review comment:
Hm ok yeah I think we'll definitely want something disconnected from wasm feature validation for this. I'll work on that.
Last updated: Jan 29 2026 at 13:25 UTC