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 newcomponent-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 (perhapswasmtime_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
pchickey commented on issue #6987:
The Nginx Unit team is also interested in this
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 (perhapswasmtime_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
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 (perhapswasmtime_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
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 (perhapswasmtime_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
alexcrichton added the wasmtime:c-api label to Issue #6987.
alexcrichton added the wasm-proposal:component-model label to Issue #6987.
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:
- peterhuene: wasmtime:c-api
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
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 howwasmtime_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...
rajsite commented on issue #6987:
related #8036
Last updated: Dec 23 2024 at 13:07 UTC