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 https://github.com/tokio-rs/mio/pull/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
https://github.com/tokio-rs/mio/pull/1931 and
https://github.com/rust-lang/socket2/pull/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.
This change introduces per-worker timer wheels in the time subsystem
to reduce the lock contention.
Key changes:
- Each worker now maintains a local timer wheel.
- Timer insertions are performed locally.
- Timer cancellations are forwarded via a
dedicated cross-worker cancellation queue.
Relevant RFC: https://github.com/tokio-rs/tokio/issues/7384
---------
Signed-off-by: ADD-SP <[email protected]>
In #6112, tests for the tracing instrumentation were introduced. They
had to live in their own test crate under `tokio/tests` because the
`tracing-mock` crate that the tests use had not yet been published to
crates.io.
Now `tracing-mock` has been published to crates.io and so the separate
test crate and separate job to run it are no longer necessary. The
tracing instrumentation tests can be placed in with the other
integration tests in the `tokio` crate.
The tests themselves have also been updated to match the changes in the
`tracing-mock` API since the version which was being used.
