Repository navigation
WASIp3 support #135
Description
Activity
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 🙏
Reacted by Mendy BergerFriendly ping. Would love to use WASIp3 with wstd, tokio, mio, ...
@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!
Reacted by Mendy BergerReacted by Mendy BergerReacted by Mendy BergerHey @ignatz, I've started working on this (see #141). Mind closing this issue in favor of that one?
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
asking: timelines and alternate runtimes
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.Regarding timelines, I don't think we'll release p3 support 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.
Perfect, thanks 🙏
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 wasip3 or wit-bindgen crates directly, not wstd, so the work here isn't really relevant to them adding support.
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 meReacted by Adam Bratschi-KayeIf I was specifically asking about
, would you still prefer me going to zulip or should I open another issue inLines 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.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.
Reacted by Sebastian JeltschOnce its working in upstream tokio, we will evaulate whether we want to more strongly recommend that approach in the README.
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
My understanding is that WASIp3 is currently not supported, which is very much expected. I can also see that there's a
p3branch and ap3PR.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:
Based on a prior comment, my understanding is that this can be worked on now and will be tied to the
wasm32-wasip3target.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.).