Repository navigation
Tracking issue for WASIp3 #141
Description
Activity
Oh I'm just realizing we (I) never ended up merging #134. We should probably start there tbh as it covers the basics for p2.
I think separating everything out like that might be a bit of overkill. From doing a sloppy implementation myself it seems like most cases can be handled with just a few inline directives within the same file (
streamwas the only place that really justified a completely different module). I can put up that code if you want to see it, but just be warned it's a mess...Ok, sounds good!
I'm inclined to let @adamrk pick his own path with regard to whether a given site should use an inline cfg or separate things out into separate
sysmodules- he's built a rapid prototype and is working through the design decisions one at a time. Introducing the features isnt the interesting part here (nor really the root of why I wasn't thrilled with #127) but how we deal with all of the details after that, and #142 is a 130 line diff whereas #134 is a 1500 line diff, so lets start with 10% the complexity and if it ends up needing more later it can be applied when and where appropriate. Its a lot harder to delete unneeded complexity later than it is to avoid adding it now.
Plan
The ultimate goal is to have
wstduse WASIp2 when compiled towasm32-wasip2and WASIp3 when compiling towasm32-wasip3, with essentially the same APIs.Until rust-lang/rust#161940 has landed we'll create mutually exclusive
p2andp3features onwstd, wherep2will be enabled by default andp3will only be run in CI during development, not meant for actual use. Then we can switch thefeaturedirectives totarget_envdirectives when the work is complete andwasm32-wasip3is tier 2.Breaking Changes
ioand TCP APIs innetwork with&references and will switch to requiring&mut. This is becausep2is a single threaded environment, whereasp3is not. This change will be made to both targets to keep them in sync.AsyncInputStream::newtakes awasip2::InputStream) these will naturally change to use the equivalent WASIp3 types. This will only be breaking when upgrading to the WASIp3 target.wasip3crate has its ownTasktype whichwstdcould use directly instead ofasync_task::Task. If done this would be another breaking change between the two targets.Checklist
cfgforwasip2target #144&->&mutbreaking API changes required for WASIp3 #145mainmacro for WASIp3 #148runtimeon WASIp3 #152randon WASIp3 #153timeon WASIp3 #154ioon WASIp3 #155neton WASIp3 #161httpon WASIp3 #164wstd-axumon WASIp3p2/p3features and usetarget_envinstead #147async_task::Tasktowasip3::Task'staticconstraint fromp3version ofblock_on#151