add WASIp2 support via `wasi-libc` by dicej · Pull Request #1931 · tokio-rs/mio

dicej · 2026-02-20T20:59:12Z

This adds support for WASIp2 networking using the poll(2)-based selector and leaving most of the details to wasi-libc.

This includes a new Waker implementation since WASIp2 has neither mulithreading, nor pipe(2), nor eventfd(2). Eventually, wasi-libc's support for WASIp3 will have both multithreading and pipe(2), so that port will be simpler.

I've triaged each previously-disabled-on-WASI integration test into one of three categories:

Enabled for p2; (still) disabled for p1
Disabled for both p1 and p2 (e.g. due to use of thread::spawn)
- We should be able to enable some of these for p3 once it has multithreading
Temporarily disabled for p2 due to bugs in wasi-libc and/or wasmtime-wasi
- These bugs have all been fixed, but have not yet made their way to a stable release

Note that I've added a TestWASI job to CI to run the tests using Wasmtime.

I've taken care to ensure that the existing wasm32-wasip1 support has not regressed. If desired, I could follow this up with a PR which removes p1 support entirely given its limited utility, which would reduce the amount of #[cfg] clutter and maintenance burden.

This adds support for WASIp2 networking using the `poll(2)`-based selector and leaving most of the details to `wasi-libc`. This includes a new `Waker` implementation since WASIp2 has neither mulithreading, nor `pipe(2)`, nor `eventfd(2)`. Eventually, `wasi-libc`'s support for WASIp3 will have both multithreading and `pipe(2)`, so that port will be simpler. I've triaged each previously-disabled-on-WASI integration test into one of three categories: - Enabled for p2; (still) disabled for p1 - Disabled for both p1 and p2 (e.g. due to use of `thread::spawn`) - We should be able to enable some of these for p3 once it has multithreading - Temporarily disabled for p2 due to bugs in `wasi-libc` and/or `wasmtime-wasi` - These bugs have all been fixed, but have not yet made their way to a stable release Note that I've added a `TestWASI` job to CI to run the tests using Wasmtime. I've taken care to ensure that the existing `wasm32-wasip1` support has not regressed. If desired, I could follow this up with a PR which removes p1 support entirely given its limited utility, which would reduce the amount of `#[cfg]` clutter and maintenance burden.

src/net/udp.rs

Snowiiii · 2026-02-20T22:02:22Z

Why not WASIp3?, it should be out next week afaik

Thomasdezeeuw

Took a quick look, this looks a lot better to me, thanks for this.

tests/util/mod.rs

src/sys/unix/net.rs

src/sys/unix/mod.rs

.github/workflows/ci.yml

src/net/udp.rs

src/sys/unix/waker/eventfd.rs

src/sys/unix/waker/single_threaded.rs

tests/tcp_stream.rs

tests/udp_socket.rs

src/net/udp.rs

src/sys/unix/tcp.rs

Thomasdezeeuw

This is getting quite close. Two open questions left. For the CI maybe we switch to cargo check in this pr and punt the actual testing to #1932?

.github/workflows/ci.yml

Thomasdezeeuw · 2026-02-23T12:15:19Z

src/sys/unix/selector/poll.rs

+                notified = waker_events != 0;
+                num_fd_events = if notified { num_events - 1 } else { num_events }
+            } else {
+                waker_events = 0;


This might cause an issue when people check the waking event's readiness, as it will report false for everything.

Maybe we should set it to POLLIN if self.notify_waker.woken()? If we go this route we can also simply the code by only setting waker_events differently. notified and num_fd_events can use the old/pipe waker code.

AFAICT, the only place we use waker_events is here, but I believe that the body of that if statement is unreachable on WASI due to SelectorState::wake being disabled.

Of course, that raises other questions:

Should SelectorState::wake be enabled on WASI? I added the config gate because the compiler said it was unused, but I didn't dig into whether it should be used.

If the answer to the above is "no", then when would Waker::woken actually return true on WASI? The only place I see Waker::wake called is in the modify_fds function used by reregister, and in that case it appears to be a no-op since Waker::ack_and_reset is called when Waker::wake returns Ok(()) (which it always will for the single_threaded.rs implementation), so AFAICT Waker::woken will never return true in SelectorState::select. In other words, there's a lot of dead code related to Waker in poll.rs for WASI right now, and perhaps the least confusing approach would be to cfg it all away (assuming we leave SelectorState::wake disabled).

The most common use case for waking is simply interrupting a call to Poll::poll, where the generated is usually ignored. However, an observable event is generated. So, it could be used for more than just waking where the event is actually used for something.

So to answer your question

Should SelectorState::wake be enabled on WASI?

I don't know. It would be an observable API difference between wasi and Unix/Windows. But I don't know if it will actually matter.

Let's leave it for now and add it #1932 as a potential item.

Thomasdezeeuw · 2026-02-24T15:12:40Z

src/sys/unix/selector/poll.rs

+                notified = waker_events != 0;
+                num_fd_events = if notified { num_events - 1 } else { num_events }
+            } else {
+                waker_events = 0;


The most common use case for waking is simply interrupting a call to Poll::poll, where the generated is usually ignored. However, an observable event is generated. So, it could be used for more than just waking where the event is actually used for something.

So to answer your question

Should SelectorState::wake be enabled on WASI?

I don't know. It would be an observable API difference between wasi and Unix/Windows. But I don't know if it will actually matter.

Let's leave it for now and add it #1932 as a potential item.

Thomasdezeeuw · 2026-02-24T15:16:16Z

Thanks @dicej!

This adds networking support for the `wasm32-wasip2` target platform, which includes more extensive support for sockets than `wasm32-wasip1`. 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. 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.

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 RUSTFLAGS="--cfg tokio_unstable"`. Once we have a solid maintenance plan, we can remove that requirement.

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.

dicej mentioned this pull request Feb 20, 2026

add wasm32-wasip2 support #1836

Closed

alexcrichton reviewed Feb 20, 2026

View reviewed changes

src/net/udp.rs Outdated Show resolved Hide resolved

dicej mentioned this pull request Feb 20, 2026

add wasm32-wasip2 support tokio-rs/tokio#6893

Closed

dicej force-pushed the wasip2-using-wasi-libc branch 2 times, most recently from 5e5aff3 to 5fc5408 Compare February 20, 2026 21:46

address review feedback

1ea9c38

dicej force-pushed the wasip2-using-wasi-libc branch from 5fc5408 to 1ea9c38 Compare February 20, 2026 21:48

Thomasdezeeuw reviewed Feb 20, 2026

View reviewed changes

dicej mentioned this pull request Feb 20, 2026

Address WASIp2 TODOs once wasi-libc and wasmtime-wasi patches land in stable releases #1932

Open

5 tasks

address review feedback

71338bf

Darksonn reviewed Feb 21, 2026

View reviewed changes

src/net/udp.rs Show resolved Hide resolved

src/sys/unix/tcp.rs Show resolved Hide resolved

Thomasdezeeuw reviewed Feb 23, 2026

View reviewed changes

use curl to download Wasmtime per review feedback

d3abdc1

Thomasdezeeuw approved these changes Feb 24, 2026

View reviewed changes

Thomasdezeeuw merged commit f9e5868 into tokio-rs:master Feb 24, 2026
62 of 63 checks passed

Thomasdezeeuw mentioned this pull request Feb 24, 2026

FreeBSD 13 CI seg faulted #1933

Open

dicej mentioned this pull request Feb 24, 2026

add wasm32-wasip2 networking support dicej/tokio#1

Open

dicej mentioned this pull request Feb 24, 2026

add wasm32-wasip2 networking support tokio-rs/tokio#7933

Draft

Conversation

dicej commented Feb 20, 2026

Uh oh!

Uh oh!

Snowiiii commented Feb 20, 2026

Uh oh!

Thomasdezeeuw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Thomasdezeeuw left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Thomasdezeeuw Feb 23, 2026

Choose a reason for hiding this comment

Uh oh!

dicej Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Thomasdezeeuw Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

Thomasdezeeuw Feb 24, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Thomasdezeeuw commented Feb 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

dicej Feb 23, 2026 •

edited

Loading