bytecodealliance / bytecodealliance/wstd

Tracking issue for WASIp3

Open
#141 6 comments 1 reaction 0 assignees View on GitHub
Dominant language
Rust
Stars
133
Forks
19
Avg merge
6d 19h
Merged PRs (30d)
5

Description

## Plan

The ultimate goal is to have `wstd` use WASIp2 when compiled to `wasm32-wasip2` and WASIp3 when compiling to `wasm32-wasip3`, with essentially the same APIs.

Until https://github.com/rust-lang/rust/pull/161940 has landed we'll create mutually exclusive `p2` and `p3` features on `wstd`, where `p2` will be enabled by default and `p3` will only be run in CI during development, not meant for actual use. Then we can switch the `feature` directives to `target_env` directives when the work is complete and `wasm32-wasip3` is tier 2.

## Breaking Changes

- The stream APIs in `io` and TCP APIs in `net` work with `&` references and will switch to requiring `&mut`. This is because `p2` is a single threaded environment, whereas `p3` is not. This change will be made to both targets to keep them in sync.
- Some APIs expose the underlying WASIp2 types (e.g. [`AsyncInputStream::new`](https://docs.rs/wstd/latest/wstd/io/struct.AsyncInputStream.html#method.new) takes a `wasip2::InputStream`) these will naturally change to use the equivalent WASIp3 types. This will only be breaking when upgrading to the WASIp3 target.
- (Up for discussion) The `wasip3` crate has its own `Task` type which `wstd` could use directly instead of `async_task::Task`. If done this would be another breaking change between the two targets.

## Checklist
- [x] #144
- [ ] #145
- [ ] #148
- [ ] Implement `runtime` on WASIp3
- [ ] Implement `rand` on WASIp3
- [ ] Implement `time` on WASIp3
- [ ] Implement `io` on WASIp3
- [ ] Implement `net` on WASIp3
- [ ] Implement `http` on WASIp3
- [ ] Implement `wstd-axum` on WASIp3
- [x] #147
- [ ] (Optional) Switch from `async_task::Task` to `wasip3::Task`
- [ ] #151

Contributor guide

Open the contributing guide

Research direction

Read the Plan and Breaking Changes, then open one unchecked checklist item such as #145, #148, or #151 and inspect the corresponding WASIp2 implementation in the named subsystem. Compare its current target and feature handling with the WASIp3 requirements. Done means the selected subsystem is implemented for WASIp3 and its development CI path works.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, wasm
Domain
operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
32/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.