Skip to content

Add async support to the component model C API#12973

Open
chaynabors wants to merge 1 commit intobytecodealliance:mainfrom
chaynabors:add-component-async-c-api
Open

Add async support to the component model C API#12973
chaynabors wants to merge 1 commit intobytecodealliance:mainfrom
chaynabors:add-component-async-c-api

Conversation

@chaynabors
Copy link
Copy Markdown
Contributor

@chaynabors chaynabors commented Apr 6, 2026

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_async
  • wasm_component_model_async_builtins
  • wasm_component_model_async_stackful
  • wasmtime_component_func_call_async
  • wasmtime_component_linker_instantiate_async
  • wasmtime_component_linker_instance_add_func_async
  • wasmtime_component_linker_add_wasip2_async
  • wasmtime_component_linker_add_wasi_http_async

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

@chaynabors chaynabors force-pushed the add-component-async-c-api branch from 405336c to ab667f1 Compare April 6, 2026 19:14
@chaynabors chaynabors marked this pull request as ready for review April 6, 2026 19:32
@chaynabors chaynabors requested a review from a team as a code owner April 6, 2026 19:32
@chaynabors chaynabors requested review from alexcrichton and removed request for a team April 6, 2026 19:32
@chaynabors chaynabors force-pushed the add-component-async-c-api branch from ab667f1 to 7784a33 Compare April 6, 2026 19:48
@github-actions github-actions bot added the wasmtime:c-api Issues pertaining to the C API. label Apr 6, 2026
Copy link
Copy Markdown
Member

@alexcrichton alexcrichton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Comment on lines +79 to +83
#ifdef WASMTIME_FEATURE_COMPONENT_MODEL_ASYNC

#ifdef __cplusplus
extern "C" {
#endif
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could this go within the above WASMTIME_FEATURE_COMPONENT_MODEL block to avoid needing to redo the extern "C" bits?

#ifdef WASMTIME_FEATURE_COMPONENT_MODEL_ASYNC

#ifdef __cplusplus
extern "C" {
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similar to above, can this block move upwards to avoid duplicating the extern "C"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasmtime:c-api Issues pertaining to the C API.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

c-api: Async support for the component model

2 participants