Stream: wasmtime

Topic: Wasip3 async model

Cwasi4wasm (Jun 26 2025 at 16:08):

Hello, I was curious if wasi p3 is still using polling internally. We introduce streams and futures but was more wondering about the technology that facilitates these types. Thinking about moving my event loop to p3 and just needed a mental model

Joel Dice (Jun 26 2025 at 16:45):

In p3, there are two ways you can wait for async operations (which we call "waitables", e.g. subtasks representing async import calls, stream/future reads/writes, etc.):

• Call the waitable-set.wait intrinsic function, which will block until at least one of the waitables in the specified set is ready
• Return CALLBACK_CODE_WAIT from the callback function of an async-lifted export function, which indicates that the callback should be called again once at least one of the waitables in the set is ready

The latter is generally preferable, since it allows other tasks in the same instance to run concurrently. Some time after 0.3.0 is released, we'll also add support for "stackful" async exports which allow the host to make multiple concurrent calls to the same component, each with its own stack, and each of those can use waitable-set.wait without limiting concurrency. That's already implemented in the wasip3-prototyping repo today, but won't be an official part of the component model until a later 0.3.x release.

Happy to answer any other questions you might have.

Joel Dice (Jun 26 2025 at 16:51):

BTW, the Rust bindings generator in wit-bindgen uses the CALLBACK_CODE_WAIT approach, allowing application code to export async functions in a natural way without requiring an async runtime (e.g. Tokio) in guest code. My mental model is that the host is providing the async runtime and the guest is communicating with it via intrinsic functions and callback return codes.

Cwasi4wasm (Jun 26 2025 at 16:57):

Oh that is interesting im thinking the use of CALLBACK_CODE_WAIT if I have a group of async methods I could check the list for which ones have a CALLBACK_CODE_WAIT in a competed fashion. I guess every time an steams and futures are encountered, wasmtime automatically puts it in the internal table.

I was also wondering will wasi-libc be updated with p3 as well?(it takes time for sure but I was mostly just wondering)

Joel Dice (Jun 26 2025 at 17:05):

No work has started on p3 support in wasi-libc yet. I'm hoping to start that in the not-too-distant future.

Joel Dice (Jun 26 2025 at 17:16):

The way CALLBACK_CODE_WAIT works is something like this:

• Host calls async-lifted export in guest
• Guest calls e.g. 3 async-lowered imports (let's assume none of them complete synchronously), producing 3 waitables representing the subtasks created by those calls
• Guest also starts a write to a stream, producing another waitable
• Guest has nothing left to do but wait for one or more of those 4 waitables to complete, so it creates a waitable-set, adds all 4 waitables to that set, returns CALLBACK_CODE_WAIT | (waitable_set_handle << 4) to the host
• Host does whatever else it needs to do (e.g. run other tasks) until at least one of those waitables completes
• Host calls the guest's callback, passing it a EVENT_SUBTASK or EVENT_STREAM_WRITE code (depending on which waitable is ready) and the waitable that's ready (plus the number of elements written in the case of EVENT_STREAM_WRITE)
• Guest does whatever it wants with that event, possibly creating new waitables and adding them to the set
• Guest returns CALLBACK_CODE_WAIT | (waitable_set_handle << 4) to the host again when appropriate
• etc. until the guest task decides it has no more to do, in which case it returns CALLBACK_CODE_EXIT, which tells the host the task is complete

Cwasi4wasm (Jun 26 2025 at 17:19):

That's awesome. Thank you so much for the explanation I might also take a look at wit-bindgen, I usually read that when I want to see a "spec in action".

Thanks again Dice!

Last updated: Dec 06 2025 at 06:05 UTC