Emoji-gate synchronous future/stream read/write#641
Merged
lukewagner merged 1 commit intoWebAssembly:mainfrom Apr 30, 2026
Merged
Emoji-gate synchronous future/stream read/write#641lukewagner merged 1 commit intoWebAssembly:mainfrom
lukewagner merged 1 commit intoWebAssembly:mainfrom
Conversation
I understand that this change is "late in the game" for component-model-async things with WASIp3 around the corner, but in light of bytecodealliance/wasmtime#13212 I'd like to try to at least propose gating the ability to use `{future,stream}.{read,write}` synchronously for the initial WASIp3 0.3.0 release. I'm not aware of any preexisting language bindings actually using these functions, for example all `wit-bindgen` languages are using the `async` version. Given that lack of use, and now-cropping-up interesting questions, I'd like to ideally gate these to be sure to have enough time to come back in the future and thoroughly consider the interleavings and repurcussions here. Specifically this change proposes moving the non-`async` functionality of these intrinsics behind the 🚝 feature gate. This preexisting feature gate mostly gated async-related builtins but it's generalized now to basically be "more options on more builtins" as a sort of grab-bag for now.
This was referenced Apr 27, 2026
Member
|
Makes sense to me to gate this if we're not using it from any producer toolchains atm; it's just an optimization. |
dicej
approved these changes
Apr 28, 2026
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Apr 28, 2026
This commit renames the previous `wasm_component_model_async_builtins` feature to `wasm_component_model_more_async_builtins` and then moves synchronous future/stream reads/writes behind this feature. This is inspired by bytecodealliance#13212 and corresponds to WebAssembly/component-model#641 plus bytecodealliance/wasm-tools#2507.
alexcrichton
added a commit
to alexcrichton/wasmtime
that referenced
this pull request
Apr 29, 2026
This commit renames the previous `wasm_component_model_async_builtins` feature to `wasm_component_model_more_async_builtins` and then moves synchronous future/stream reads/writes behind this feature. This is inspired by bytecodealliance#13212 and corresponds to WebAssembly/component-model#641 plus bytecodealliance/wasm-tools#2507.
PhoebeSzmucer
pushed a commit
to PhoebeSzmucer/wasm-tools
that referenced
this pull request
Apr 29, 2026
…e#2507) This commit renames the previous `CM_ASYNC_BUILTINS` feature to `CM_MORE_ASYNC_BUILTINS` and then moves synchronous future/stream reads/writes behind this feature. This is inspired by bytecodealliance/wasmtime#13212 and corresponds to WebAssembly/component-model#641.
pull Bot
pushed a commit
to kokizzu/wasmtime
that referenced
this pull request
Apr 29, 2026
…e#13217) This commit renames the previous `wasm_component_model_async_builtins` feature to `wasm_component_model_more_async_builtins` and then moves synchronous future/stream reads/writes behind this feature. This is inspired by bytecodealliance#13212 and corresponds to WebAssembly/component-model#641 plus bytecodealliance/wasm-tools#2507.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I understand that this change is "late in the game" for component-model-async things with WASIp3 around the corner, but in light of bytecodealliance/wasmtime#13212 I'd like to try to at least propose gating the ability to use
{future,stream}.{read,write}synchronously for the initial WASIp3 0.3.0 release. I'm not aware of any preexisting language bindings actually using these functions, for example allwit-bindgenlanguages are using theasyncversion. Given that lack of use, and now-cropping-up interesting questions, I'd like to ideally gate these to be sure to have enough time to come back in the future and thoroughly consider the interleavings and repurcussions here.Specifically this change proposes moving the non-
asyncfunctionality of these intrinsics behind the 🚝 feature gate. This preexisting feature gate mostly gated async-related builtins but it's generalized now to basically be "more options on more builtins" as a sort of grab-bag for now.