You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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++.
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...
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.
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?
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
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.
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.
Reacted by Alex Crichton, yowl, Milan Raj, WeiYuemin and GalladeGuy
I'd love to try out the component model in my Go apps via wasmtime-go, but my understanding is that it's not possible to even start working on the Go implementation until the C API supports the component model.
I believe other non-Rust host languages are in the same boat.
There's a fair bit of polishing to do there (starting with splitting in smaller intermediate PRs), I think I eventually will be able to tackle that, but not clear exactly when (I didn't expect to have time during the holidays in any case).
@MangoPeachGrape do you know of any other outstanding items to do for the C API of the component model? Would it be best now to create follow-up issues for those?
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.
Activity
rockwotj commentedon Mar 1, 2024
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 plateI will probably not be getting to this. Please pick it up if you can work on this
ac000 commentedon Mar 22, 2024
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 commentedon Mar 27, 2024
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).
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 commentedon Jun 5, 2024
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 commentedon Jun 7, 2024
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 commentedon Jun 20, 2024
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.
Correct, the component model host bindings for any other language than Rust is blocked on getting this done.
lanfeust69 commentedon Nov 14, 2024
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_newno longer needs aComponentparameter.mattjohnsonpint commentedon Jan 15, 2025
Happy new year! Any updates on this?
I'd love to try out the component model in my Go apps via wasmtime-go, but my understanding is that it's not possible to even start working on the Go implementation until the C API supports the component model.
I believe other non-Rust host languages are in the same boat.
ReneeGA2020 commentedon Jan 16, 2025
Found a PR started by @lanfeust69
#9812
No one has approved it yet.
lanfeust69 commentedon Jan 16, 2025
There's a fair bit of polishing to do there (starting with splitting in smaller intermediate PRs), I think I eventually will be able to tackle that, but not clear exactly when (I didn't expect to have time during the holidays in any case).
alexcrichton commentedon Jul 28, 2025
@MangoPeachGrape do you know of any other outstanding items to do for the C API of the component model? Would it be best now to create follow-up issues for those?
alexcrichton commentedon Aug 21, 2025
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.