Wasmtime GitHub notifications bot (Mar 01 2024 at 14:22): Wasmtime GitHub notifications bot (Mar 01 2024 at 14:22):rockwotj opened issue #8036:
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
Wasmtime GitHub notifications bot (Mar 01 2024 at 14:22):rockwotj commented on issue #8036:
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
Wasmtime GitHub notifications bot (Mar 22 2024 at 15:36):ac000 commented on issue #8036:
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
Wasmtime GitHub notifications bot (Mar 27 2024 at 14:59):rockwotj commented on issue #8036:
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. 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.
Wasmtime GitHub notifications bot (Mar 27 2024 at 14:59):rockwotj edited a comment on issue #8036:
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.
Wasmtime GitHub notifications bot (Jun 05 2024 at 06:39):vlhomutov commented on issue #8036:
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?
Wasmtime GitHub notifications bot (Jun 07 2024 at 00:41):fforjan commented on issue #8036:
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
Wasmtime GitHub notifications bot (Jun 20 2024 at 09:50):rockwotj commented on issue #8036:
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.
Wasmtime GitHub notifications bot (Nov 14 2024 at 08:29):lanfeust69 commented on issue #8036:
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.
Wasmtime GitHub notifications bot (Nov 29 2024 at 21:42):rockwotj edited a comment on issue #8036:
~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~
I will probably not be getting to this. Please pick it up if you can work on this
Last updated: Dec 23 2024 at 12:05 UTC