add wasm32-wasip2 networking support#7933
Conversation
Darksonn
added
A-tokio
dicej
force-pushed
the
wasip2-take2
branch
2 times, most recently
from
e5f53db to
288442f
Compare
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.
|
Update: I've update the The latest |
| #![cfg(all(feature = "full", not(target_os = "wasi"), not(miri)))] // Wasi doesn't support bind | ||
| // No `socket` on miri. | ||
| // WASIp1 doesn't support bind | ||
| // No `socket` on miri. | ||
| #![cfg(all( | ||
| feature = "net", | ||
| feature = "macros", | ||
| feature = "rt", | ||
| feature = "io-util", | ||
| not(all(target_os = "wasi", target_env = "p1")), | ||
| not(miri) | ||
| ))] |
There was a problem hiding this comment.
What's happening here? Why are you making this change?
There was a problem hiding this comment.
Previously, the tests in this file would not run on WASI at all due to the #![cfg(...)] directive. I've updated the cfg directive so that the tests will run on WASIp2 and later by changing the not(target_os = "wasi") clause to not(all(target_os = "wasi", target_env = "p1")) and making the feature = "full" clause more precise, covering the features actually needed by these tests, given that WASI does not yet support feature = "full".
2 participants
Motivation
This adds networking support for the
wasm32-wasip2target platform, which includes more extensive support for sockets thanwasm32-wasip1.Solution
The bulk of the changes are in tokio-rs/mio#1931. This patch mainly tweaks a few
cfgdirectives to indicatewasm32-wasip2's additional capabilities.Note that this is a draft PR 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-wasip2target to CI and triaged each test which was previously disabled for WASI into one of three categories:wasi-libcbugfixes 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 astokio::net::lookup_host, etc.) should work unchanged viawasi-libcand worker threads.Currently, building for WASIp2 requires
RUSTFLAGS="--cfg tokio_unstable". Once we have a solid maintenance plan, we can remove that requirement.