Stream: git-wasmtime

Topic: wasmtime / PR #11055 c-api: component-model: Resource tab...

view this post on Zulip Wasmtime GitHub notifications bot (Jun 16 2025 at 21:27):

MangoPeachGrape opened PR #11055 from MangoPeachGrape:c-api/component-model/resource-table to bytecodealliance:main:

I've gotten quite stuck on how to do resources, so I decided to try WASI first.

Some things I'm unsure about:

On resources, I think I'm getting stuck on ResourceTypeKind::Host using TypeId.

Would all the resources use a CApiResource type on the rust side, and then use a string discriminant, or something like that?

Do you have any other ideas?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 16 2025 at 21:27):

MangoPeachGrape requested alexcrichton for a review on PR #11055.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 16 2025 at 21:27):

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

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

alexcrichton commented on PR #11055:

Should the context be inside an Option and then expect() in the WASI traits, or is the default context fine?

For ResourceTable I think it's ok to leave it there on-by-default, but for wasmtime_wasi::p2::WasiCtx yeah let's have that be an option which panics if it's not set.

How to specify your own context, perhaps wasmtime_context_set_wasi_p2()?

Right now wasi.h is a binding to the wasip1 builder API, and I think we'll want a new API for the wasip2 builder API (e.g. bindings for wasmtime_wasi::p2::WasiCtx::builder). Once that structure is built yeah a new API of wasmtime_context_set_wasi_p2 would take the builder and then insert it into the store. Then afterwards the Option in the store would be Some and everything should work.

On resources, I think I'm getting stuck on ResourceTypeKind::Host using TypeId.

This has tripped me up in the past as well, I think it might be reasonable to add ResourceTypeKind::HostId(u64) where the host just provides a 64-bit integer. That could be added for the C API and that way the C API could take integers to differentiate resource types?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 17:18):

MangoPeachGrape commented on PR #11055:

we'll want a new API for the wasip2 builder API (e.g. bindings for wasmtime_wasi::p2::WasiCtx::builder)

Where should I place this? Maybe include/wasmtime/wasi/p2.h? Or should I place it next to the include/wasi.h, i.e. include/wasi_p2.h?

And how should the naming convention be? Similar to how it is in wasi.h, e.g. wasi_p2_config_inherit_stdout(), or something more similar to the rust side, maybe wasmtime_wasi_p2_builder_inherit_stdout()?

I think it might be reasonable to add ResourceTypeKind::HostId(u64) where the host just provides a 64-bit integer. That could be added for the C API and that way the C API could take integers to differentiate resource types?

Seems like a nice solution, I think I'll try that in a next PR?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 19:56):

alexcrichton commented on PR #11055:

I've long wanted to move wasi.h and scope it under the "wasmtime" namespace. Additionally we try to consider "wasipN" a unit as oppose to "wasi pN", so how about include/wasmtime/wasip2.h and wasmtime_wasip2_config_*?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 20:41):

MangoPeachGrape updated PR #11055.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 20:45):

MangoPeachGrape commented on PR #11055:

Does that look correct?

I've long wanted to move wasi.h and scope it under the "wasmtime" namespace

Should I do that also here? Would that include adding wasmtime_wasip1_ prefix to everything?

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 20:49):

MangoPeachGrape updated PR #11055.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 20:52):

alexcrichton created PR review comment:

s/add_wasi/add_wasip2/

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 20:52):

alexcrichton submitted PR review:

Does that look correct?

Looks good! Just one minor rename, and with some comments in the headers for the new functions looks good. Mind adding a test or two as well? (doesn't need to be too too fancy)

I've long wanted to move wasi.h and scope it under the "wasmtime" namespace

Should I do that also here? Would that include adding wasmtime_wasip1_ prefix to everything?

Nah let's save that for later. At this point it's probably best to just not touch it and achieve these goals with the updates going forward. I don't think there's any real need to rename the preexisting APIs at this time.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 17 2025 at 21:17):

MangoPeachGrape updated PR #11055.

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

alexcrichton submitted PR review.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 18 2025 at 15:26):

alexcrichton merged PR #11055.

Last updated: Dec 06 2025 at 07:03 UTC