Hey all; I just published a new blog post about how to build an async runtime for WASI 0.2 https://blog.yoshuawuyts.com/building-an-async-runtime-for-wasi/. Figured this might be a useful reference for the Rust Async ecosystem to add support for WASI 0.2!
The blog and the crate made the Pollable and the poll from WASI 0.2 very approachable. I thought I could understand it all except for a small comment in the code that you also said in the blog, that through careful reading one might find it silly that awake is being called since the WASI 0.2 is single threaded so it can only wake the one waker.
Couldn't the WASI 0.2 host find multiple Pollables's ready before returning from poll?
Do you mean something more specific than the WASM module is single-threaded? Do you mean there could only be one outstanding '.wait' call at any given time in your runtime since there is no notion of spawn? I will admit I'm confused a bit by the ability for the futures crate to allow multiple Futures to be polled concurrently. I thought that would mean there could be multiple wakers present in your runtime but I also have the vague idea that a waker is tied to a runtime task? :man_shrugging:
I really like your last section that talks about why an executor isn't warranted. And reading through the comment in "reactor.rs" again, you do explain it would be common for libraries to create their own wakers. So maybe I just let myself get confused because I am a novice but it didn't seem silly at all to be waking in a loop.
The macros in futures and the traits in futures_concurrency make me wonder if a crate I have worked on that had relied on the Tokio current_thread runtime to be able to spawn local tasks could be written to be free of any actual runtime dependency.
There can be multiple wakers even when single threaded. Some future combinators create their own wakers which allow the future combinator to know which sub futures it needs to poll again.
Last updated: Jan 10 2026 at 20:04 UTC