Wasmtime GitHub notifications bot (Apr 06 2026 at 18:52): Wasmtime GitHub notifications bot (Apr 06 2026 at 18:52):chaynabors opened PR #12973 from chaynabors:add-component-async-c-api to bytecodealliance:main:
Closes #12955
Adds async equivalents of the component model C API, following the existing core module async patterns in
async.h.New functions:
wasmtime_component_func_call_asyncwasmtime_component_linker_instantiate_asyncwasmtime_component_linker_instance_add_func_asyncwasmtime_component_linker_add_wasip2_asyncwasmtime_component_linker_add_wasi_http_async- Config:
wasm_component_model_async,wasm_component_model_async_builtins,wasm_component_model_async_stackfulA few notes on the design:
Reuses
wasmtime_call_future_tfrom core async. Same poll/delete lifecycle.The async func callback does all C value conversion before the await point so the async block doesn't capture non-Send types.
No store-level value storage reuse (unlike core module's
wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need a C++ CallFuture wrapper that doesn't exist for core modules either. Should I add one?
Feature gated behind
component-model-async, enabled by default in release builds. Should this be disabled by default?No C API tests for async exist in the codebase today, including for core modules. Happy to add one if there's a preferred pattern.
Wasmtime GitHub notifications bot (Apr 06 2026 at 18:53):chaynabors edited PR #12973:
Closes #12955
Adds async equivalents of the component model C API, following the existing core module async patterns in
async.h.New functions:
wasm_component_model_asyncwasm_component_model_async_builtinswasm_component_model_async_stackfulwasmtime_component_func_call_asyncwasmtime_component_linker_instantiate_asyncwasmtime_component_linker_instance_add_func_asyncwasmtime_component_linker_add_wasip2_asyncwasmtime_component_linker_add_wasi_http_asyncA few notes on the design:
- Reuses
wasmtime_call_future_tfrom core async. Same poll/delete lifecycle.- The async func callback does all C value conversion before the await point so the async block doesn't capture non-Send types.
- No store-level value storage reuse (unlike core module's
wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.- C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need a C++ CallFuture wrapper that doesn't exist for core modules either. Should I add one?
- Feature gated behind
component-model-async, enabled by default in release builds. Should this be disabled by default?- No C API tests for async exist in the codebase today, including for core modules. Happy to add one if there's a preferred pattern.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:14):chaynabors updated PR #12973.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:32):chaynabors has marked PR #12973 as ready for review.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:32):chaynabors requested wasmtime-core-reviewers for a review on PR #12973.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:32):chaynabors requested alexcrichton for a review on PR #12973.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:38):chaynabors edited PR #12973:
Closes #12955
Adds async equivalents of the component model C API, following the existing core module async patterns in
async.h.New functions:
wasm_component_model_asyncwasm_component_model_async_builtinswasm_component_model_async_stackfulwasmtime_component_func_call_asyncwasmtime_component_linker_instantiate_asyncwasmtime_component_linker_instance_add_func_asyncwasmtime_component_linker_add_wasip2_asyncwasmtime_component_linker_add_wasi_http_asyncA few notes on the design:
- Reuses
wasmtime_call_future_tfrom core async. Same poll/delete lifecycle.- The async func callback does all C value conversion before the await point so the async block doesn't capture non-Send types.
- No store-level value storage reuse (unlike core module's
wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.- C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need a C++ CallFuture wrapper that doesn't exist for core modules either. Should I add one?
- Feature gated behind
component-model-async, enabled by default in release builds. Should this be disabled by default?- No C API tests for async exist in the codebase today, including for core modules. Happy to add one if there's a preferred pattern.
- Update: I also include the async.h at the top with the rest of the includes. It's harmless since the file itself is entirely conditional in the interior but could be inlined further down. There wasn't any precedence and that gets messy so I didn't.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:38):chaynabors edited PR #12973:
Closes #12955
Adds async equivalents of the component model C API, following the existing core module async patterns in
async.h.New functions:
wasm_component_model_asyncwasm_component_model_async_builtinswasm_component_model_async_stackfulwasmtime_component_func_call_asyncwasmtime_component_linker_instantiate_asyncwasmtime_component_linker_instance_add_func_asyncwasmtime_component_linker_add_wasip2_asyncwasmtime_component_linker_add_wasi_http_asyncA few notes on the design:
- Reuses
wasmtime_call_future_tfrom core async. Same poll/delete lifecycle.- The async func callback does all C value conversion before the await point so the async block doesn't capture non-Send types.
- No store-level value storage reuse (unlike core module's
wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.- C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need a C++ CallFuture wrapper that doesn't exist for core modules either. Should I add one?
- Feature gated behind
component-model-async, enabled by default in release builds. Should this be disabled by default?- No C API tests for async exist in the codebase today, including for core modules. Happy to add one if there's a preferred pattern.
- I also include the async.h at the top with the rest of the includes. It's harmless since the file itself is entirely conditional in the interior but could be inlined further down. There wasn't any precedence and that gets messy so I didn't.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:47):chaynabors commented on PR #12973:
Found a small side effect of this change where the C++ headers themselves wouldn't always compile under certain configurations. Fixing now.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:47):chaynabors edited a comment on PR #12973:
Found a small side effect of this change where the C++ headers themselves wouldn't always link under certain configurations. Fixing now.
Wasmtime GitHub notifications bot (Apr 06 2026 at 19:48):chaynabors updated PR #12973.
Wasmtime GitHub notifications bot (Apr 06 2026 at 22:56):github-actions[bot] added the label wasmtime:c-api on PR #12973.
Wasmtime GitHub notifications bot (Apr 07 2026 at 15:23):chaynabors edited PR #12973:
Closes #12955
Adds async equivalents of the component model C API, following the existing core module async patterns in
async.h.New functions:
wasm_component_model_asyncwasm_component_model_async_builtinswasm_component_model_async_stackfulwasmtime_component_func_call_asyncwasmtime_component_linker_instantiate_asyncwasmtime_component_linker_instance_add_func_asyncwasmtime_component_linker_add_wasip2_asyncwasmtime_component_linker_add_wasi_http_asyncA few notes on the design:
- No store-level value storage reuse (unlike core module's
wasm_val_storage). The sync component model C API doesn't have it either, so this could be a follow-up for both sync and async.- C++ header only wraps the WASI/HTTP linker functions since the future-returning functions would need some fort of CallFuture wrapper that doesn't exist for core modules either. Should I add one?
- Feature gated behind
component-model-async, enabled by default in release builds. Should this be disabled by default?- No C API tests for async exist in the codebase today, including for non-component modules. Happy to add some scaffolding if we want it, and have a preference for how it's done.
- I include async.h at the top with the rest of the includes. It's harmless since the file itself is entirely conditional in the interior but the import could be inlined further down. There wasn't any precedence and that gets messy so I didn't.
Wasmtime GitHub notifications bot (Apr 07 2026 at 15:24):chaynabors deleted a comment on PR #12973:
Found a small side effect of this change where the C++ headers themselves wouldn't always link under certain configurations. Fixing now.
Wasmtime GitHub notifications bot (Apr 07 2026 at 18:35):alexcrichton submitted PR review:
Thanks for this! Just some minor stylistic comments below, but overall looks great.
There's currently no tests in this PR, and while I realize that we don't currently have tests for async in the C/C++ APIs, would you be up for adding some at least simple tests for calling functions/host functions/etc?
Wasmtime GitHub notifications bot (Apr 07 2026 at 18:35):alexcrichton created PR review comment:
Could this go within the above
WASMTIME_FEATURE_COMPONENT_MODELblock to avoid needing to redo theextern "C"bits?
Wasmtime GitHub notifications bot (Apr 07 2026 at 18:35):alexcrichton created PR review comment:
Similar to above, can this block move upwards to avoid duplicating the
extern "C"?
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:11):chaynabors updated PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:22):chaynabors updated PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:40):alexcrichton submitted PR review:
Thanks again for this!
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:40):alexcrichton added PR #12973 Add async support to the component model C API to the merge queue.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:48):chaynabors updated PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:53):chaynabors commented on PR #12973:
@alexcrichton, found a bug with the implementation and resolved it. It appears that the PR is still queued. That feels a little scary from a security perspective so I figured I'd flag? I'm not sure if it's attempting to merge 85dad84 or dec2b79.
Thanks for the nits, I fixed both of them and added tests for module-level and component model async as I'm sure you've already realized. Thanks for the quick turnaround.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:55):chaynabors edited a comment on PR #12973:
@alexcrichton, found a bug with the implementation and resolved it. It appears that the PR is still queued. That feels a little scary from a security perspective so I figured I'd flag? I'm not sure if it's attempting to merge 85dad84 or dec2b79.
Thanks for the nits, I fixed both of them and added tests for module-level and component model async as I'm sure you've already realized. I'll short circuit the ask for tests next time. Thanks for the quick turnaround.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:59):chaynabors commented on PR #12973:
I'm not sure how to pull out of merge queue. Apologies as I try some things.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:59):chaynabors converted PR #12973 Add async support to the component model C API to a draft.
Wasmtime GitHub notifications bot (Apr 08 2026 at 17:59):chaynabors requested alexcrichton for a review on PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:05):github-merge-queue[bot] removed PR #12973 Add async support to the component model C API from the merge queue.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:05):chaynabors has marked PR #12973 as ready for review.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:06):chaynabors edited a comment on PR #12973:
I'm not sure how to pull out of merge queue. Apologies as I try some things. Makes sense that I wouldn't be able to.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:07):chaynabors deleted a comment on PR #12973:
I'm not sure how to pull out of merge queue. Apologies as I try some things. Makes sense that I wouldn't be able to.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:20):chaynabors edited a comment on PR #12973:
Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate but I could be wrong. Would make a lot more sense for the approved commit to have been merged otherwise the merge queue is inhermetic?
In any case, checks appear to be bugging out in GitHub, but they pass locally. Sorry for the trouble.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:21):chaynabors edited a comment on PR #12973:
Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate but I could be wrong. Would make a lot more sense for the approved commit before the push to have been merged otherwise the merge queue is inhermetic?
In any case, checks appear to be bugging out in GitHub, but they pass locally. Sorry for the trouble.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:27):chaynabors commented on PR #12973:
Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate but I could be wrong. Would make a lot more sense for the approved commit to have been merged otherwise the merge queue is inhermetic?
In any case, checks appear to be bugging out locally. Sorry for the trouble.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:28):chaynabors edited a comment on PR #12973:
Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate. Would make a lot more sense for the approved commit before the push to have been merged otherwise the merge queue is inhermetic?
In any case, checks appear to be bugging out in GitHub, but they pass locally. Sorry for the trouble.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:29):alexcrichton closed without merge PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:29):alexcrichton reopened PR #12973 from chaynabors:add-component-async-c-api to bytecodealliance:main.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:30):chaynabors edited a comment on PR #12973:
Alright, it appears that when I pushed to the branch tests got cancelled and took a bit to propagate. Would make a lot more sense for the approved commit before the push to have been merged otherwise the merge queue is unhermetic?
In any case, checks appear to be bugging out in GitHub, but they pass locally. Sorry for the trouble.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:30):alexcrichton commented on PR #12973:
Ah no worries, github merge queues are a bit weird if someone with non-write-access to the repo pushes while it's in the queue, but nothing bad happens it just means that the previous version of the PR is tested/enqueued. The main weird part is that had tests passed this PR would have merged without your updated changes, but that's mostly a github thing.
The tests actually failed due to a completely unrelated spurious failure, but hey worked out!
And yeah sometimes github doesn't actually run PR CI. No idea why, but closing/reopening a PR often fixes that.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:30):alexcrichton has enabled auto merge for PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 18:47):alexcrichton added PR #12973 Add async support to the component model C API to the merge queue.
Wasmtime GitHub notifications bot (Apr 08 2026 at 19:12):alexcrichton merged PR #12973.
Wasmtime GitHub notifications bot (Apr 08 2026 at 19:12):alexcrichton removed PR #12973 Add async support to the component model C API from the merge queue.
Last updated: Apr 12 2026 at 23:10 UTC