Stream: wasi

Topic: Question about async and pollable

Forder (Jan 22 2026 at 15:37):

For a while I've been wondering, why is it that wasi is leaning towards polling-based async design? I presume there's a good reason but I've been scratching my head for a while and I can't really think of one. Why not something like:

resource future {
    stream: ...
    await: func(response-handler);
}
resource response-handler {
    receive: func( ... );
}

with a usage such as (pseudocode just to show the concept)

fn foo() {
    let some_future = do_something_async();
    /* potentially do some stuff */
    some_future.await( Handler::new());
}
struct Handler {};
impl ResponseHandler for Handler {
  fn receive( data: ... ) {
    /* continue work here */
  }
}

This way there is no need for polling, the async function simply calls into the original caller once it has the data. Sure, this causes a loop of A calls into B::something_async and then it's B that calls back into A, but when our B is the host (which when you're implementing wasi is almost deffinetelly the case) this is a non-issue.

I can definitely see the disadvantages of this dividing the code having to put a part of the body into an impl block but I don't think that's entirely unreasonable, especially when we're using codegen for bindings anyways. I also see the issue of receive() having different signatures depending on what it is that you're doing but I don't think the response-handler resource has to necessary be reusable, the few extra resource types don't really look like that big of a deal.

Maybe it's just too convoluted, dunno, just curious

Joel Dice (Jan 22 2026 at 16:28):

If you're referring to WASIp2's wasi:io package and its pollable resource type, you're right that it's awkward to use and makes composition-with-concurrency impractical. Fortunately, wasi:io has been removed in favor of Component Model Concurrency in WASIp3, allowing bindings generators to use the concurrency idioms of their target guest languages (e.g. async/await for Rust, JS, Python, and C#; goroutines for Go, etc.)

Last updated: Jan 29 2026 at 13:25 UTC