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
tokio-stream 0.1.18 added `Stream::size_hint` for
`ReceiverStream` and `UnboundedReceiverStream` (PR #7492),
which calls `Receiver::is_closed()` and `Receiver::len()`
(added in tokio 1.37.0) and `Receiver::capacity()` and
`Receiver::max_capacity()` (added in tokio 1.38.0).
The declared minimum of tokio 1.15.0 is no longer sufficient,
causing compilation failures when resolved via
`-Z direct-minimal-versions`.
Refs: #7492
Linux thread names are truncated at 15 characters.
Currently, Tokio threads show up as "tokio-runtime-w", whereas
shortening "runtime" to "rt" would make the thread name perfectly fit
in the 15 character limit.
The unix implementation remembers whether it failed or not, so the
windows implementation should do so as well. This PR also replaces the
`(Once, AtomicState)` pair with `OnceLock` and tries to remember the
original errno value.