c-api: component model

[rockwotj]

Feature

Expose the component model in the C API for other languages than Rust.

Benefit

Components in all the languages! (on the host side)

Implementation

I have a POC I created here with some feedback I will incorporate.

https://github.com/bytecodealliance/wasmtime/pull/7801

However prior to making further progress on this task, there needs more work on the test infrastructure for the C API. There was a rough plan in Zulip discussed about using GoogleTest and C++.

Alternatives

[rockwotj]

I am planning on getting to this, but progress will be slow, so if someone else wants to pick this up, I am happy to take it off my plate

[ac000]

Hi,

This is really great to see!

We (NGINX Unit) wrote a WebAssembly language module using the Wasmtime C API last summer.

However when it came to supporting the component model, we discovered this was totally lacking on the C side of things.

In fact Alex actually ended up writing us a Rust based wasm language module to support components.

However being a C guy, I am naturally chomping at the bit to have a NGINX Unit wasm language module in C that supports the component model.

In terms of core functionality is your PoC in a testable state? I.e would it be able to actually run say a WASI 0.2.0 component?

While I am a C programmer, I can only sort of kludge bits of Rust (and maybe C++, C++ and C have really been distinct languages from each other for quite some time) together, but don't really know what I'm doing there...

Cheers, Andrew

[rockwotj]

Hey Andrew, glad you're interested in this as well! I have not yet had time to invest in this. I believe my PoC had all the needed bits to invoke a component, but there is more needed (exposing host functions to components for example), and things like resources were entirely unsupported. It's not actually been tested against a real component, I was wanting to get some feedback first. I have alligator energy here, and will eventually get around to this, starting with a test suite (using Google Test).

run say a WASI 0.2.0 component?

Even once I get the component model working, I don't personally have plans to expose WASI 0.2 in the C API (at least the implementation that Wasmtime provides), we have our own WASI implementation we plug in ourselves (that uses our scheduler, allocator, etc). I'm not sure of the state of WASI p1 in the C API, but we can open a followup ticket after this is completed.

[vlhomutov]

Any update/plan on this? C API is a must-have for components.

Is it possible to enable loading a component as plain WASM module? I mean: component is just a WASM module + metadata in special file format. I understand that loading component properly requires additional works. But what is the problem to extract plain WASM from module file and load it as usual module?

[fforjan]

Would my understanding that, without the Component in C APi, it would also not be available into a .NET Host ? We were interesting to explorer the component model with our .Net application for extensions but we are blocked with a simple Module, not Component

[rockwotj]

Updates

Unfortunately I will not be able to get to this anytime soon. I don’t know if this is something the Wasmtime core team is considering taking up. You can ask on Zulip.

it would also not be available into a .NET Host

Correct, the component model host bindings for any other language than Rust is blocked on getting this done.

[lanfeust69]

I've been using the C-api for component model for a while (in this branch, starting from #7801).

This works by limiting a lot the set of types allowed in host-provided functions, and needing to declare in advance all the allowed signatures, two very serious limitations.

But I'm finally giving a go to a more general implementation, especially now that, after rebasing, LinkerInstance::func_new no longer needs a Component parameter.