rudikone opened issue #13705:
Hello.
I'm evaluating Wasmtime as an embedding runtime from Java through the public Wasmtime C API.
I noticed that Async Component Model support (
component-model-async) appears to be available in the Rust API, including APIs such as:
Func::call_concurrentFunc::start_call_concurrentFunc::finish_call_concurrentStore::run_concurrentfunc_wrap_concurrent- native handling of component-model
future<T>andstream<T>At the same time, I cannot find equivalent functionality in the public C API.
From the documentation it looks like the C API currently exposes the older async mechanism based on:
wasmtime_config_async_support_setwasmtime_func_call_asyncwasmtime_call_future_twhich solves host-side asynchronous execution, but does not appear to expose the Async Component Model scheduler or guest task APIs.
Questions:
- Is exposing Async Component Model functionality in the C API part of the current roadmap?
Is there already an issue tracking support for:
call_concurrentrun_concurrent- concurrent guest Tasks
- component-model
future/streamfunc_wrap_concurrentIs the current recommendation for non-Rust embedders to:
- use Rust as an adapter layer and expose custom FFI,
- or wait for first-class C API support?
Are there known architectural blockers preventing a direct mapping of the Async Component Model APIs into the C API?
The motivation is support for WASI 0.3 style component composition from Java without introducing an intermediate Rust host layer.
Thanks.
alexcrichton added the wasmtime:c-api label to Issue #13705.
alexcrichton added the wasm-proposal:component-model-async label to Issue #13705.
alexcrichton commented on issue #13705:
Yes
*_concurrentfunctions aren't exposed just yet in the C API. There'll need to be some work necessary to get those exposed, but my hope is that it's relatively similar toStoreContextMut<'_, ..>and how it's exposed. No one's lined up to do this just yet, however.
Last updated: Jul 29 2026 at 05:03 UTC