Stream: wasmtime

Topic: Component Model C-API

Tyler Rockwood (Nov 22 2023 at 02:49):

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

Alex Crichton (Nov 22 2023 at 02:52):

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!

Tyler Rockwood (Nov 22 2023 at 03:01):

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.

Joel Dice (Nov 22 2023 at 14:50):

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.

Tyler Rockwood (Nov 22 2023 at 15:01):

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

Tyler Rockwood (Jan 15 2024 at 16:16):

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

Tyler Rockwood (Jan 15 2024 at 16:22):

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.

Tyler Rockwood (Jan 15 2024 at 16:41):

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

Joel Dice (Jan 16 2024 at 16:16):

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.

Tyler Rockwood (Jan 17 2024 at 04:03):

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:

1. It's not clear to me if the name of index of enums, flags and variants is the stable interface. The rust impl uses the strings, but that's a little awkward in the C-API compared to integers, and the underlying runtime type is the integer.
2. The conversion between C-API types and wasmtime::component::Val is less than ideal. I think there could be a 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.
3. I haven't wrapped my head around resources enough to incorporate those.
4. The "normal" Rust generated bindings write their custom types directly using canoncial lifting/lowering and while that would be nice to expose through the C-API, I don't have resources to work on that at the moment. It would require coordination with some code generation tooling, and I'm guessing the C-API would just expose an interface for reading/writing the canonical ABI directly from/to guest memory.

Alex Crichton (Jan 17 2024 at 16:01):

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.

Tyler Rockwood (Jan 17 2024 at 20:44):

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.

Tyler Rockwood (Jan 17 2024 at 20:57):

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.

Tyler Rockwood (Jan 20 2024 at 14:57):

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

Alex Crichton (Jan 22 2024 at 18:45):

Sorry I've been dragging my feet getting back to this, I'll try to review that PR today or tomorrow. Thanks for it!

Tyler Rockwood (Jan 22 2024 at 18:50):

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.

Alex Crichton (Jan 22 2024 at 20:34):

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.

Alex Crichton (Jan 22 2024 at 20:35):

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

Alex Crichton (Jan 22 2024 at 20:35):

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

Alex Crichton (Jan 22 2024 at 20:36):

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

Tyler Rockwood (Jan 22 2024 at 20:39):

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: Nov 22 2024 at 16:03 UTC