wasip3 support

[shuowpro]

Based on the WASI roadmap, the wasip3 preview has been released on wasmtime 37, and it will be officially released on Feb, 2026, wasip3 is a very important version and it should unlock tons of scenarios, what is the plan of supporting it?

[yowl]

As far as async and future support in thr component model.for c# , this is a work in progress. There are some tests in the wit-bindgen repo, and c# is going to slowly get support for passing those tests. Your best bet for tracking that is to follow the PRs .

[shuowpro]

wit-bindgen is meant for C# to be used as a component called by other runtimes. I think we also need to make it support wasmtime calling other wasip3 components. Do we have plan to support it?

[martindevans]

With regards to async; I tried to implement support for it a while ago (see #279), but unfortunately it turned out to be impossible.

The way in which wasmtime implements async on Windows (using fibers) is incompatible with dotnet (dotnet doesn't allow any usage of fibers). This isn't something that's likely to change in either end.

[yowl]

Async support in C# will support calls from other components, and the intention is to support threads when it becomes available in wasi.

[lfpraca]

My understanding was that fibers were necessary for exposing async host functions as blocking to the guest, saving the guest's stack when the function was called, working asynchronously and then restoring thet stack when completed.

Using WASM 0.3's new async primitives, my understanding is that the host would call the guest back on future completion, somewhat similarly to rust's Future::poll, which I would think means that the host doesn't have to save the guest's stack at all.

Do you have some insight regarding this, @martindevans ?

[martindevans]

I haven't looked into WASI 0.3 much yet, so I don't have any specific insights there I'm afraid.

However if I had to guess: I think Wasmtime will still use a fiber to save and restore the stack. Because you might yield back through host code you somehow need to save that non-WASM state too, so a stackless system seems unworkable without exposing internal details to every host function.

I actually have an async system built on asyncify which has a similar problem. it can save the WASM stack with asyncify but needs cooperation from host functions to resume through them. Fibers would "just work".