Repository navigation
WASIp3 support #135
Description
My understanding is that WASIp3 is currently not supported, which is very much expected. I can also see that there's a p3 branch and a p3 PR.
I'm creating this ticket mostly to have something to track and maybe better understand the plan 🙏
Just as a snapshot, when you try to use wstd with the wasip2 build target and wasip3 async WIT interfaces, everything builds and runs until an async host interface is called, where the host panics with something akin to:
thread '<unnamed>' (1) panicked at /home/sebastian/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/wit-bindgen-0.51.0/src/rt/async_support/waitable.rs:193:13:
assertion failed: !task.is_null()
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Based on a prior comment, my understanding is that this can be worked on now and will be tied to the wasm32-wasip3 target.
Please let me know if I got anything wrong. If and when you folks have timelines, I would love to hear.
Thanks for all your great work 🙏
(On a tangent, with some mio WASIp2 support now in place, I was also wondering what the overarching plan is? If I understood the comms correctly, wstd was at least initially planned as a stop gap. The readme still raads: It exists primarily to enable people to write async-based applications in Rust before async-std, smol, or tokio land support for Wasm Components and WASI 0.2. Once those runtimes land support, it is recommended users switch to use those instead.).
Activity
ignatz commentedon Jul 28, 2026
Friendly ping.
It may be surprising to users that wasmtime claims to be WASIp3 ready but none of the guest environments seemingly supporting it (would love to be wrong). Some clarification, documentations and/or timelines would be greatly appreciated 🙏
ignatz commentedon Aug 27, 2026
Friendly ping. Would love to use WASIp3 with wstd, tokio, mio, ...
yoshuawuyts commentedon Aug 29, 2026
@ignatz hi yes, sorry for the delay. We're indeed working on this. I've been meaning (and failing) to properly address this for a few months now, instead just vendoring in my branch as needed.
@pchickey and I talked about this yesterday, and one of his colleagues is going to take over the implementation so it actually gets done. Hard to give you an ETA, but we're both going to prioritize review for this so we can get this out sooner!
adamrk commentedon Sep 3, 2026
Hey @ignatz, I've started working on this (see #141). Mind closing this issue in favor of that one?
ignatz commentedon Sep 3, 2026
I don't want to sound ungrateful, I'm genuinely stoked someone is working on this. That said, I filed this issue seeing that folks are working on this asking: timelines and alternate runtimes. I was still hoping for some answers. Apart from that, you should totally track you work however works best for you
adamrk commentedon Sep 3, 2026
Regarding timelines, I don't think we'll release
p3support until the wasip3 target is stable (maybe rustc 1.100 or 1.101 so before the end of the year?), but we should be able to do it as soon as that's done. For tracking that, take a look at rust-lang/rust#161940. The implementation should be merged into the repo here in the next few weeks so if you want to try it out before then you can do so.Regarding alternate runtimes, I think you'll get more information by opening issues with the runtimes you're interested in. They'll probably be building on top of the
wasip3orwit-bindgencrates directly, notwstd, so the work here isn't really relevant to them adding support.ignatz commentedon Sep 4, 2026
Perfect, thanks 🙏
In principle that sounds reasonable, I just don't think mio will feel responsible, since the integration was donated and is maintained/owned by your org tokio-rs/mio#1836. In essence: bytecodealliance owns two implementations and wstd says:
It exists primarily to enable people to write async-based applications in Rust before async-std, smol, or tokio land support for Wasm Components and WASI 0.2. Once those runtimes land support, it is recommended users switch to use those instead.. I'm not sure where would be the best place to ask - maybe you can help meadamrk commentedon Sep 4, 2026
I see - for general bytecode alliance questions, the best place to bring it up would be on the zulipchat (probably in the
wasichannel).ignatz commentedon Sep 9, 2026
If I was specifically asking about
wstd/README.md
Lines 49 to 53 in b9b83a7
wstd? I would be nice if afterwards the documented recommendation could be updated to reflect the current state of the world, so that everyone can discover it.pchickey commentedon Sep 9, 2026
That paragraph is still true, aside from async-std being defunct, it will just expand to encompass both WASI 0.2 and 0.3. The purpose of wstd will continue to be providing an idiomatic programming surface for targeting wasip2 and p3, with as much of that in common between the two revisions as reasonably possible. We still don't have the goal of being a runtime forever, and as support in other runtimes matures we would love to consider whether its appropriate to retire wstd. Some of our BA peers are working actively on projects that will help unlock wasip3 support in tokio, but its not yet ready to be used AFAIK. Once its working in upstream tokio, we will evaulate whether we want to more strongly recommend that approach in the README.
ignatz commentedon Sep 10, 2026
Is it not working in upstream? It was merged in March: tokio-rs/mio#1931. According to tokio-rs/mio#1939 it was release in mio v1.2 starting March.
I would still politely ask to update the statement already. With mio support out, it's tough to reason about. If I target WASIp2 today, which one should I use? Different folks worked on the mio integration, maybe there's also just a disconnect? Any persisted clarification would be helpful