`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
The previous documentation stated:
'As such, Receiver::poll returns Ok(Ready(None))'
This was misleading: when all Sender handles are dropped, recv does NOT
immediately return None. Buffered messages already in the channel can
still be received. Only after all senders are dropped AND the channel
has been fully drained does recv return None.
Also update the method reference from the internal Receiver::poll to the
public API: Receiver::recv and Receiver::poll_recv.
Closes#6053
The previous wording 'if a task that wishes to acquire the write lock is
at the head of the queue, read locks will not be given out' was
misleading: it implied that readers are only blocked when the writer is
first in the queue. In reality, due to the FIFO ordering, any write
request queued *before* a read request will block that reader.
Replace with a more accurate description: 'a read lock will not be given
out until all write lock requests that were queued before it have been
acquired and released.'
Closes#6901
