Is the Component Model implementation in Wasmtime in a state where it's ready to be exposed via the C-API? I haven't looked at what all this will entail, but wanted to get someone's thoughts before going down the rabbit hole
More-or-less yeah, although it's not a trivial undertaking by any means. It'll require pretty significant design of how values are represented and communicated. Nothing fundamental to overcome though, just a chunk of work!
Cool - I probably won't have time to look into it until the start of the new year, but I'll poke around and I may have some questions later about how it all works.
This would be most welcome, and would make it much easier to bring e.g. wasmtime-py
and wasmtime-go
up-to-speed with respect to WASI Preview 2, resources, composed components, etc.
For sure - I have my own embedding in C++ that I'm keen on using the component model in the future, although I'll have lots of benchmarking and the like to do first
It seems most of the component model uses the typed API (for example the code generated by bindgen!). Is there an example anywhere of how to use the "untyped" or "dynamic" API? That's going to be easier to plumb through the C API
Ah I see some examples in fuzzing and wast code, looks like types are always looked up by using the function that is being called. I think I see how we can map this to the C API.
I guess I question I have is to why some of the values are optional, for example, why is ResultVal's value an Option
? I get the need for boxing, but I don't understand when that could be None
.
Screenshot-2024-01-15-at-10.40.58AM.png
In WIT (and in the binary representation of a component), a result
might not have a payload, or might only have a payload for the ok
case but not the err
case (or vice versa). In WIT this is expressed as e.g. result
(no payload for ok
or err
), result<foo>
(no payload for err
), or result<_, foo>
(no payload for ok
). Thus, the Option
in ResultVal
represents the possibility of no payload.
In earlier versions of WIT and the component model, there was a unit
type which was used to represent "no payload", but that has since been removed.
I have a proof of concept for the C API + Component Model here (needs a lot more work): https://github.com/bytecodealliance/wasmtime/compare/main...rockwotj:wasmtime:main
A few things:
new_unchecked
for things like List
, Record
, etc OR there could be a wasmtiem::component::RawVal
enum that the C-API could expose that would allow more efficient conversions with less (or no!) copies and no duplicated typechecking.Thanks for this! Would you be up for making a PR to continue discussions on? I haven't reviewed your branch yet but that's probably a good starting point.
Additionally, would you have the appetite for helping us out to test this? Right now we very few tests for the C API beyond the relatively simplistic examples in the repository. Given the (what I expect is there) complexity of the component model version it'd be best if we could have tests in-repo to showcase as both examples and ensuring things keep working. Also given that this doesn't currently exist though it might be a bit of a big ask for you, so I don't want to necessarily require it but wanted to probe your thinking on this.
Yeah, I'd be good with moving to a PR for discussions, it will just be a draft, because I don't actually intend to merge this POC, but would like to discuss a couple alternatives.
As for testing, yes we should certainly have real tests for the C API instead of just having the examples run and exit with status 0 :) Is there any formal plan you'd like to see or have opinions on? Personally I'd love to setup a little CMake project with GoogleTest to ensure stuff works correctly. The examples are good too, but at some level you probably need a real unit test framework. I'm not sure what other testing you had in mind, but starting with some unit tests on the C-API is probably a good first step.
Oh I guess another question I have is if these tests need to be written in C or if writing stuff in C++ is OK. I prefer C++ for a variety of reasons, but ya'll will be maintaining this, so am happy to get your thoughts too.
I guess another option is to write tests in rust using these APIs, I'm not sure how desirable that is.
Would love some opinions here for what maintainers would prefer to see, I can certainly enumerate what I prefer, but that's not necessarily the best for wasmtime and maintainers.
https://github.com/bytecodealliance/wasmtime/pull/7801
Sorry I've been dragging my feet getting back to this, I'll try to review that PR today or tomorrow. Thanks for it!
No worries! I am not in any rush here. Just FYI I'm not really looking to have that PR merged or the code really thoroughly reviewed. I am more interested in discussing some of the points that I brought up in this thread or in the PR description.
Ok I'm taking a look at things, I'll respond to the PR on the PR but to respond to some questions you had here:
'm not sure what other testing you had in mind, but starting with some unit tests on the C-API is probably a good first step.
CMake + GoogleTest sounds good to me. I don't have any preference here due to lack of experience of tackling this task (testing C/C++ APIs), and I suspect many other Wasmtime folks are in the same bucket. So long as it's easy to set up and test locally I think it'll work out ok.
Oh I guess another question I have is if these tests need to be written in C or if writing stuff in C++ is OK.
I think C++ is fine, it's "close enough" to C and gets us the coverage we want of "this C header file parses and can be used from C++" well
I wouldn't recommend Rust because the main purpose of the tests would be to test that it works from C/C++ and we can have at least one example of wrangling build systems
basically I'd do whatever you're comfortable with and you seem to know more about this space than us so we're happy to pick up the idioms you set forth
Awesome thanks. I'll make sure whatever gets setup has copious amounts of documentations for folks new to C/C++ so hopefully it isn't a maintenance burden.
Last updated: Dec 23 2024 at 14:03 UTC