Add a Notes section to all five try_* methods on pipe::Sender and
pipe::Receiver explaining that the runtime's I/O driver only delivers
readiness events after control is yielded back to it, so calling
try_read/try_write before any .await returns WouldBlock even when the
operation could otherwise succeed.
This is the same readiness model used by every other Tokio I/O type;
the pipe docs simply did not previously call it out. Refs #7625.
---------
Co-authored-by: Mattia Pitossi <[email protected]>
This reverts commit 1604bc3351.
Unfortunately, this commit introduced a regression that causes programs
using `spawn_blocking` to hang (see #8056). To fix the regression, we
need to undo this change and publish a v1.52.1 release as soon as
possible.
In the future, we may wish to bring back a sharded queue for
`spawn_blocking` tasks, either based on the implementation added in
#7757 or a new one. However, since this is a substantial change to the
runtime internals, I think such a change should probably be done as an
unstable, opt-in `tokio::runtime::Builder` setting initially, so that we
don't regress existing users. I had hoped we could do this now, but
unfortunately, the sharded queue implementation from #7757 is kind of
tightly coupled with the rest of the `spawn_blocking` machinery and
cannot be easily swapped out --- and the hang still occurs with
`NUM_SHARDS` set to 1, so there isn't an easy way to turn it on and off.
Therefore, in the interest of getting a fix out ASAP, this is just a
simple revert.
Fixes#8056
`Chan::recv_many` intends to assert that no slots
have been consumed when exiting with `Ready` via
the `rx_closed` code path.
Instead of asserting no items were added to the
buffer, it asserted buffer emptiness, incorrectly
making assumptions about the provided buffer.
When `recv_many` was called on an empty channel
with idle semaphore after the receiver was closed,
the method would panic.
The branch coverage had been previously missing.
This changeset corrects the assertion
and adds tests covering the code path.
Fixes#7990.
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.
Multiple macro expansions were previously assumming the existence of
some standard library symbols to both be in-scope and referring to the
right symbol, and not only having the same identifier.
This has now been refactored into using reexports from the `support`
module under the `macros` module. Some other macro invocations were also
using absolute standard library paths instead of calling into the afore
mentioned module through the special `$crate` macro. This has been
changed, thus also reexporting some other items in `support`.
Previously, if a `notify_waiters()` was followed by a `notify_one()`,
an unpolled `Notified` future created before the `notify_waiters()`
call would consume the `NOTIFIED` permit created by the
`notify_one()` call.
This commit fixes this by verifying the `notify_waiters_calls` count
before optimistically attempting to acquire the `NOTIFIED` permit. If
the count indicates a `notify_waiters()` call has already happened, the
future transitions directly to `State::Done` and leaves the permit
intact for other waiters.
Fixes: #7965
* chore: Do not show "Available on non-loom only." doc label
Closes#7976
Uses the unstable #[doc(cfg()]. https://github.com/rust-lang/rust/issues/43781
* Use build.rs to detect nightly builds
* Use `docsrs` instead of `nightly`. Drop build.rs
* Use doc(auto_cfg(hide(config_name)))
* Use same nightly on CirrusCI (FreeBSD) as on Github Actions CI
Alice Ryhl