Stream: git-wasmtime

Topic: wasmtime / issue #6987 Add component model support to the...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 10 2023 at 02:07):

seanisom opened issue #6987:

Feature

Add component model support to the c-api (particularly the ability run a component from a c-api host).

Benefit

Much of the WebAssembly world is currently (re)tooling around the component model as it approaches MVP. The ability to run components will quickly become more critical with the finalization of the wasi preview 2 abi. Currently C/C++ is the only wit-bindgen supported guest language and example in the new component-docs repo that does not have a path to run from a host in the same language.

Implementation

I'd be happy to take a go at this modeled roughly around the Rust crate with the current c-api idioms (for example wasmtime_config_wasm_component_model(conf, true);, a component aware linker (perhaps wasmtime_linker_define_component_model(linker);), etc. I haven't looked deep enough into the implementation yet to see if there is significant core functionality to enable this past the standard glue code and lifecycle management for c objects.

Alternatives

Eventually this will become necessary - it's a matter of timing. I suspect that this has just not yet been implemented due to the instability of wasmtime::component.

CC: Discussed with @sunfishcode at the BA hackathon

view this post on Zulip Wasmtime GitHub notifications bot (Sep 10 2023 at 03:12):

pchickey commented on issue #6987:

The Nginx Unit team is also interested in this

view this post on Zulip Wasmtime GitHub notifications bot (Sep 10 2023 at 08:12):

seanisom edited issue #6987:

Feature

Add component model support to the c-api (particularly the ability run a component from a c-api host).

Benefit

Much of the WebAssembly world is currently (re)tooling around the component model as it approaches MVP. The ability to run components will quickly become more critical with the finalization of the wasi preview 2 abi. Currently C/C++ is the largest fully-supported language with a clear path to producing guests (through wit-bindgen) that does not have a path to run from a host in the same language.

Implementation

I can take a first step with this modeled roughly around the Rust crate with the current c-api idioms (for example wasmtime_config_wasm_component_model(conf, true);, a component aware linker (perhaps wasmtime_linker_define_component_model(linker);), etc. I haven't looked deep enough into the implementation yet to see if there is significant core functionality to enable this past the standard glue code and lifecycle management for c objects.

Alternatives

Eventually this will become necessary - it's a matter of timing. I suspect that this has just not yet been implemented due to the instability of wasmtime::component.

CC: Discussed with @sunfishcode at the BA hackathon

view this post on Zulip Wasmtime GitHub notifications bot (Sep 10 2023 at 08:12):

seanisom edited issue #6987:

Feature

Add component model support to the c-api (particularly the ability run a component from a c-api host).

Benefit

Much of the WebAssembly world is currently (re)tooling around the component model as it approaches MVP. The ability to run components will quickly become more critical with the finalization of the wasi preview 2 abi. Currently C/C++ is the largest fully-supported language with a clear path to producing guests (through wit-bindgen) that does not have a path to run from a host in the same language.

Implementation

I can take a first pass at this modeled roughly around the Rust crate with the current c-api idioms (for example wasmtime_config_wasm_component_model(conf, true);, a component aware linker (perhaps wasmtime_linker_define_component_model(linker);), etc. I haven't looked deep enough into the implementation yet to see if there is significant core functionality to enable this past the standard glue code and lifecycle management for c objects.

Alternatives

Eventually this will become necessary - it's a matter of timing. I suspect that this has just not yet been implemented due to the instability of wasmtime::component.

CC: Discussed with @sunfishcode at the BA hackathon

view this post on Zulip Wasmtime GitHub notifications bot (Sep 10 2023 at 08:13):

seanisom edited issue #6987:

Feature

Add component model support to the c-api (particularly the ability run a component from a c-api host).

Benefit

Much of the WebAssembly world is currently (re)tooling around the component model as it approaches MVP. The ability to run components will quickly become more critical with the finalization of the wasi preview 2 abi. Currently C/C++ is the largest fully-supported language with a clear path to producing component guests (through wit-bindgen) that does not have a path to run from a host in the same language.

Implementation

I can take a first pass at this modeled roughly around the Rust crate with the current c-api idioms (for example wasmtime_config_wasm_component_model(conf, true);, a component aware linker (perhaps wasmtime_linker_define_component_model(linker);), etc. I haven't looked deep enough into the implementation yet to see if there is significant core functionality to enable this past the standard glue code and lifecycle management for c objects.

Alternatives

Eventually this will become necessary - it's a matter of timing. I suspect that this has just not yet been implemented due to the instability of wasmtime::component.

CC: Discussed with @sunfishcode at the BA hackathon

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2023 at 19:21):

alexcrichton added the wasmtime:c-api label to Issue #6987.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2023 at 19:21):

alexcrichton added the wasm-proposal:component-model label to Issue #6987.

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2023 at 19:22):

github-actions[bot] commented on issue #6987:

Subscribe to Label Action

cc @peterhuene

<details>
This issue or pull request has been labeled: "wasmtime:c-api"

Thus the following users have been cc'd because of the following labels:

To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.

Learn more.
</details>

view this post on Zulip Wasmtime GitHub notifications bot (Sep 11 2023 at 19:28):

alexcrichton commented on issue #6987:

Thanks for opening an issue for this! You're right in that this hasn't quite bubbled to the top of any priority list yet which is why it isn't done, but it's something that definitely should get done!

My prediction for the main difficulty of this feature will be how to transfer values back and forth. The type grammar of core wasm is quite simple which made this a non-issue for core wasm's C API support, but for components it's significantly different. The easiest route is probably going to be to mirror Val into C more-or-less. This will not be really all that efficient in terms of calls because datatypes like lists will be copied in/out and everything will be dynamically type-checked. For example I don't know how wasmtime_func_call_unchecked could get a C/C++ equivalent that skips all the type-checks. That's not a showstopper for any sort of initial support, however. Still though there's tricky questions around how exactly memory management will work with values. I'm not sure the best answer here.

More minor it might be worth bikeshedding a bit to avoid a wasmtime_component_* prefix on everything which is quite long. Not that I have much of an idea about a better name...

view this post on Zulip Wasmtime GitHub notifications bot (Sep 04 2024 at 21:03):

rajsite commented on issue #6987:

related #8036

view this post on Zulip Wasmtime GitHub notifications bot (Aug 21 2025 at 23:01):

alexcrichton closed issue #6987:

Feature

Add component model support to the c-api (particularly the ability run a component from a c-api host).

Benefit

Much of the WebAssembly world is currently (re)tooling around the component model as it approaches MVP. The ability to run components will quickly become more critical with the finalization of the wasi preview 2 abi. Currently C/C++ is the largest fully-supported language with a clear path to producing component guests (through wit-bindgen) that does not have a path to run from a host in the same language.

Implementation

I can take a first pass at this modeled roughly around the Rust crate with the current c-api idioms (for example wasmtime_config_wasm_component_model(conf, true);, a component aware linker (perhaps wasmtime_linker_define_component_model(linker);), etc. I haven't looked deep enough into the implementation yet to see if there is significant core functionality to enable this past the standard glue code and lifecycle management for c objects.

Alternatives

Eventually this will become necessary - it's a matter of timing. I suspect that this has just not yet been implemented due to the instability of wasmtime::component.

CC: Discussed with @sunfishcode at the BA hackathon

view this post on Zulip Wasmtime GitHub notifications bot (Aug 21 2025 at 23:01):

alexcrichton commented on issue #6987:

I'm going to close this issue in favor of more specific open issues since thanks to @MangoPeachGrape the component model is pretty well supported in the C API now that I think it's best to focus on specific issues rather than the general concept.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2026 at 17:55):

planetbeing commented on issue #6987:

I was linked to this issue by https://github.com/bytecodealliance/component-docs/blob/4e906915e9a1020657f1cf7b193cb9fd2847d7e6/component-model/src/language-support/building-a-simple-component/c.md?plain=1#L329 but since this issue is closed, the trail is cold for me to discover how to host components with C/C++. The comment that "thanks to @MangoPeachGrape the component model is pretty well supported in the C API now" is heartening but I'm at a loss as to how to use that support or even what code changes those are referring to so I can start investigating. Where can I start looking for information on this?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2026 at 18:45):

seanisom commented on issue #6987:

@planetbeing - at the time I wrote those docs for C support in the component model, no progress had been made on this work here. We switched to the Rust crate a couple of years ago and I haven't kept up with it.

It looks like no examples were added to the Wasmtime C API docs for @MangoPeachGrape 's component mode work. Looking quickly through the autogenerated doxygen docs here (wasmtime_component*), the support looks fairly complete, and analogous to the Component Model API in the Rust crate.

I'd suggest following along with the Rust crate docs, substituting the C API types above and see how far that gets you.

I'd be willing to update the Component Model API docs this month, but will need to try it and build some minimal examples first.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 04 2026 at 18:46):

seanisom edited a comment on issue #6987:

@planetbeing - at the time I wrote those docs for C support in the component model, no progress had been made on this work here. We switched to the Rust crate a couple of years ago and I haven't kept up with it.

It looks like no examples were added to the Wasmtime C API docs for @MangoPeachGrape 's component model work. Looking quickly through the autogenerated doxygen docs here (wasmtime_component*), the support looks fairly complete, and analogous to the Component Model API in the Rust crate.

I'd suggest following along with the Rust crate docs, substituting the C API types above and see how far that gets you.

I'd be willing to update the Component Model API docs this month, but will need to try it and build some minimal examples first.

Last updated: Jan 09 2026 at 13:15 UTC