Stream: git-wasmtime

Topic: wasmtime / PR #10598 c-api: Create and instantiate a comp...

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 19:20):

MangoPeachGrape opened PR #10598 from MangoPeachGrape:c-api/component-model/instance to bytecodealliance:main:

Next small chunk of #9812.

I'm not sure about the lifetime requirements of wasmtime_component_linker_instance(), is there any better way to express this?
See previous discussion: https://github.com/bytecodealliance/wasmtime/pull/9812#discussion_r1884466077

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 19:20):

MangoPeachGrape requested pchickey for a review on PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 19:20):

MangoPeachGrape requested wasmtime-core-reviewers for a review on PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 19:25):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 19:34):

alexcrichton submitted PR review:

Thanks! Would you be up for additionally writing tests now that we've got that set up? Ideally through a new C++ API but also optionally through the C API.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 20:12):

MangoPeachGrape commented on PR #10598:

Yes! I would like to write tests, but I'm not sure on some things:

I tested this locally by writing a "example" host using these functions, and running it with a guest component which doesn't import anything.
How would this be represented as test in the repo?
Would this kind of E2E test go the c-api/tests?
How would the guest component get compiled?

Also, I'm not sure if I would want to update the C++ API as well in these PRs. Would it make more sense to add tests for the C API now, and if later - when the same functionality gets exposed to C++ API, and a test written for it - made the C test obsolete, remove it?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 20:13):

MangoPeachGrape edited a comment on PR #10598:

Yes! I would like to write tests, but I'm not sure on some things:

I tested this locally by writing an "example" host using these functions, and running it with a guest component which doesn't import anything.
How would this be represented as a test in the repo?
Would this kind of E2E test go into the c-api/tests?
How would the guest component get compiled?

Also, I'm not sure if I would want to update the C++ API as well in these PRs. Would it make more sense to add tests for the C API now, and if later - when the same functionality gets exposed to C++ API, and a test written for it - made the C test obsolete, remove it?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 20:19):

alexcrichton commented on PR #10598:

My thinking is that most of the tests could use the text format of WebAssembly, meaning the test wasm file would be in-line with the test itself (this is used a lot on the Rust side for testing too). Orchestrating native-language binaries compiled to wasm to be available in the tests is possible but will be a bit of a pain.

For location, yeah I'm thinking we'd drop things in crates/c-api/tests/*.cc. And yeah if you'd prefer to start by testing the C API I think that's reasonable.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 22:01):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 22:03):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 22:32):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:07):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:07):

alexcrichton created PR review comment:

I may have missed this on other headers, but I think for this to work reliably you'll want to #include <wasmtime/conf.h> in these headers too? (basically fix the case where this header, and just this header, are included)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:07):

alexcrichton created PR review comment:

Mind deferring this type to later? I think there's going to be some tricky ownership questions we'll want to grapple with for this (e.g. handling the lifetime parameter in the Rust side of things)

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:07):

alexcrichton created PR review comment:

I think we'll want this to be similar to wasmtime_instance_t where it's not an opaque struct but instead it's a known sturct of two integers (although embeddings won't use the integers much). That'll also obviate the need for deletion of this structure too

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:47):

MangoPeachGrape submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:47):

MangoPeachGrape created PR review comment:

Do you mean not adding this and wasmtime_component_linker_instance() in this PR?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 16 2025 at 23:59):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 14:30):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 14:30):

alexcrichton created PR review comment:

Yeah I think it'd be best to defer that to a future PR to discuss possible directions for that API

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 23:04):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 17 2025 at 23:11):

MangoPeachGrape updated PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 14:31):

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 14:56):

alexcrichton merged PR #10598.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 18 2025 at 21:32):

MangoPeachGrape commented on PR #10598:

@alexcrichton What do you want in the next PR?

view this post on Zulip Wasmtime GitHub notifications bot (Apr 21 2025 at 15:05):

alexcrichton commented on PR #10598:

How about sketching out the Linker API? Basically being able to create recursive instances/etc. Perhaps hooking up the wasmtime_module_t type where you can supply a core module to a component? (in lieu of defining functions which I think is a bit harder to do as a single step)

My main concern there is that the Linker API in Rust has a lot of borrowed lifetimes which makes it nontrivial to map to other languages. Clear ownership semantics tend to work out best IMO, and it's also the case that performance is not of the utmost concern when creating a Linker. In that sense I think we may want to design this in such a way such that separate pointers in the C API aren't intrinsically linked but instead perhaps define an item-at-a-time where there's no intermediately-owned structures?

One example could be that the entire "path" to an item is passed to the C API, where each element in the path is an exported instance layer. That would then call .instance(..) as necessary in the Rust API and define the requested item at the leaf when the path is iterated over. Or... something like that, just some vague ideas.

It's not that we can't have inter-related objects in the C API, it's mostly just that I'd prefer to avoid it if possible.

Last updated: Dec 06 2025 at 07:03 UTC