`MpscReceiver` aligns with `MpscSender`. The original name appears to
not actually have been in use, for better or worse.
Along the way, sprinkle the attribute onto `mpmc::Receiver` and
`mpmc::Sender` too.
Clarified docs in std::sync::RwLock + added test to ensure that max reader count is respected
This addresses the issue with the [`std::sync::RwLock` docs](https://doc.rust-lang.org/std/sync/struct.RwLock.html) in rust-lang/rust#115338. It centers around the following lines:
> An `RwLock` will allow any number of readers to acquire the lock as long as a writer is not holding the lock.
It's true that the `RwLock` in theory should allow any number of readers to acquire the lock when a writer is not holding it, but this may not be true in the implementation and could be os dependent. I decided to replace "any number of readers" to "multiple", so that it implies that more than 1 reader can acquire the lock, but you can't necessarily take away that this value is unbounded.
@rustbot label +A-docs
Add is_disconnected functions to mpsc and mpmc channels
Add `is_disconnected()` functions to the `Sender` and `Receiver` of both `mpmc` an `mpsc` channels.
```rust
std::sync::mpmc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpmc::Receiver<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Sender<T>::is_disconnected(&self) -> bool
std::sync::mpsc::Receiver<T>::is_disconnected(&self) -> bool
```
The `mpsc` methods are locked behind the `mpsc_is_disconnected` feature gate, which has no tracking issue yet.
ACP: https://github.com/rust-lang/libs-team/issues/748
Tracking issue: https://github.com/rust-lang/rust/issues/153668
- `From<T> for ThinBox<T>`
- `From<T> for UniqueRc<T>`
- `From<T> for UniqueArc<T>`
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
This addresses the need for clarification brought up in an issue.
Specifically, it notes that some implementations may choose to panic if
they detect deadlock situations during recursive locking attempts for
both `read()` and `write()` calls.
* Provide an example highlighting that multiple read locks can be
held across different threads simultaneously.
* Remove the example that shows a situation that can potentially deadlock.
(as demonstrated in the very same documentation a few paragraphs
above)
* Improve documentation regarding the possibility of panics during
recursive read or write lock attempts.
Issues: Ambiguity in RwLock documentation about multiple read() calls...
Signed-off-by: Henner Zeller <h.zeller@acm.org>
Since non-poisoning `Condvar` take non-poisoing `Mutex`es when
`wait`ing, we do not need to take by ownership since a poison error
cannot occur while we wait.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
It is a bit confusing when reading code that uses this type since it is
not immediately obvious that it is specific to `Once`.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Stabilize `rwlock_downgrade` library feature
Tracking Issue: https://github.com/rust-lang/rust/issues/128203
Method to be stabilized:
```rust
impl<'a, T: ?Sized> RwLockWriteGuard<'a, T> {
pub fn downgrade(s: Self) -> RwLockReadGuard<'a, T> {}
}
```
~~I would like to point out that my documentation comment is longer than ideal, but at the same time I don't really know how else to show why `downgrade` is actually necessary (instead of just unlocking and relocking). If anyone has ideas for making this more concise that would be great!~~ I have made the documentation a bit more clear.
Stabilization report: https://github.com/rust-lang/rust/issues/128203#issuecomment-3016682463
Implementation: `#[feature(nonpoison_condvar)]`
Tracking Issue: https://github.com/rust-lang/rust/issues/134645
This PR continues the effort made in https://github.com/rust-lang/rust/pull/144022 by adding the implementation of `nonpoison::condvar`.
Many of the changes here are similar to the changes made to implement `nonpoison::mutex`.
There are two other changes here. The first is that the `Barrier` implementation is migrated to use the `nonpoison::Condvar` instead of the `poison` variant. The second (which might be subject to some discussion) is that `WaitTimeoutResult` is moved up to `mod.rs`, as both `condvar` variants need that type (and I do not know if there is a better place to put it now).
### Related PRs
- `nonpoison_rwlock` implementation: https://github.com/rust-lang/rust/pull/144648
- `nonpoison_once` implementation: https://github.com/rust-lang/rust/pull/144653
Since `WaitTimeoutResult` is poison-agnostic, we want to use the same
type for both variants of `Condvar`.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Adds the equivalent `nonpoison` types to the `poison::condvar` module.
These types and implementations are gated under the `nonpoison_condvar`
feature gate.
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Sidney Cammeresi