Skip to content

add wasm32-wasip2 networking support#1

Open
dicej wants to merge 1 commit intomasterfrom
wasip2-take2
Open

add wasm32-wasip2 networking support#1
dicej wants to merge 1 commit intomasterfrom
wasip2-take2

Conversation

@dicej
Copy link
Owner

@dicej dicej commented Feb 24, 2026

Motivation

This adds networking support for the wasm32-wasip2 target platform, which includes more extensive support for sockets than wasm32-wasip1.

Solution

The bulk of the changes are in tokio-rs/mio#1931. This patch mainly tweaks a few cfg directives to indicate wasm32-wasip2's additional capabilities.

Note that this is a draft PR until until
tokio-rs/mio#1931 and
rust-lang/socket2#639 have been include in stable releases of their respective projects.

Also note that I've added a test-wasi target to CI and triaged each test which was previously disabled for WASI into one of three categories:

  • Disabled on both WASIp1 and p2 due to not-yet-supported features such as multithreading
  • Disabled on p1 but enabled on p2
  • Disabled on p1 and temporarily disabled on p2 due to wasi-libc bugfixes which have been merged but not yet included in a Rust release. I'll open an issue to re-enable them when the fixes land in Rust.

Future Work

In the future, we could consider adding support for tokio::net::lookup_host. WASIp2 natively supports asynchronous DNS lookups and is single threaded, whereas Tokio currently assumes DNS lookups are blocking and require multithreading to emulate async lookups. A WASIp2-specific implementation could do the lookup directly without multithreading.

WASIp2 also supports single-threaded, asynchronous file I/O, timers, etc. We could either support those directly or wait for WASIp3's multithreading support, in which case most of tokio::fs (as well as tokio::net::lookup_host, etc.) should work unchanged via wasi-libc and worker threads.

Currently, building for WASIp2 requires both nightly Rust and RUSTFLAGS="--cfg tokio_unstable". The nightly requirement could be removed once either the feature(wasip2) is stabilized or rustix is updated not to use it. It would be nice to remove the --cfg tokio_unstable requirement as well, assuming we have a solid maintainance plan.

@dicej dicej force-pushed the wasip2-take2 branch 5 times, most recently from 2998752 to 14a69d6 Compare February 24, 2026 18:30
- name: test tokio --target wasm32-wasip2
# We currently need `+nightly` here due to some dependencies
# (e.g. `rustix`) which require `#![feature(wasip2)]`:
run: cargo +nightly nextest run --target wasm32-wasip2 --features net,macros,rt,io-util

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How much work would it be to get cargo test working? E.g. how many annotations needed to ignore tests that don't compile or fail?

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are 69 doc tests failing at either compile time or runtime, so...lots.

@dicej dicej force-pushed the wasip2-take2 branch 7 times, most recently from ed49484 to e7ea20e Compare February 24, 2026 21:26
Motivation

This adds networking support for the `wasm32-wasip2` target platform, which
includes more extensive support for sockets than `wasm32-wasip1`.

Solution

The bulk of the changes are in tokio-rs/mio#1931.  This
patch mainly tweaks a few `cfg` directives to indicate `wasm32-wasip2`'s
additional capabilities.

Note that this is a draft PR until until
tokio-rs/mio#1931 and
rust-lang/socket2#639 have been include in stable
releases of their respective projects.

Also note that I've added a `wasm32-wasip2` target to CI and triaged each test
which was previously disabled for WASI into one of three categories:

- Disabled on both WASIp1 and p2 due to not-yet-supported features such as multithreading
- Disabled on p1 but enabled on p2
- Disabled on p1 and _temporarily_ disabled on p2 due to `wasi-libc` bugfixes which have been merged but not yet included in a Rust release.  I'll open an issue to re-enable them when the fixes land in Rust.

Future Work

In the future, we could consider adding support for `tokio::net::lookup_host`.
WASIp2 natively supports asynchronous DNS lookups and is single threaded,
whereas Tokio currently assumes DNS lookups are blocking and require
multithreading to emulate async lookups.  A WASIp2-specific implementation could
do the lookup directly without multithreading.

WASIp2 also supports single-threaded, asynchronous file I/O, timers, etc.  We
could either support those directly or wait for WASIp3's multithreading support,
in which case most of `tokio::fs` (as well as `tokio::net::lookup_host`, etc.)
_should_ work unchanged via `wasi-libc` and worker threads.

Currently, building for WASIp2 requires RUSTFLAGS="--cfg tokio_unstable"`.  Once
we have a solid maintenance plan, we can remove that requirement.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants