| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make {Mutex, Condvar, RwLock}::new() const.
This makes it possible to have `static M: Mutex<_> = Mutex::new(..);` 🎉
Our implementations [on Linux](https://github.com/rust-lang/rust/pull/95035), [on Windows](https://github.com/rust-lang/rust/pull/77380), and various BSDs and some tier 3 platforms have already been using a non-allocating const-constructible implementation. As of https://github.com/rust-lang/rust/pull/97647, the remaining platforms (most notably macOS) now have a const-constructible implementation as well. This means we can finally make these functions publicly const.
Tracking issue: https://github.com/rust-lang/rust/issues/93740
|
|
`Mutex::lock()` and `RwLock::write()` are poison-guarded against panics,
in that they set the poison flag if a panic occurs while they're locked.
But if we're already in a panic (`thread::panicking()`), they leave the
poison flag alone.
That check is a bit of a waste for methods that never set the poison
flag though, namely `get_mut()`, `into_inner()`, and `RwLock::read()`.
These use-cases are now split to avoid that unnecessary call.
|
|
Co-authored-by: Weiyi Wang <wwylele@gmail.com>
|
|
The docs were saying something about "statically initializing" the
mutex, and it's not clear what this means. Remove that part to avoid
confusion.
|
|
|
|
|
|
Add functions to un-poison Mutex and RwLock
See discussion at https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3
|
|
|
|
|
|
|
|
|
|
See discussion at https://internals.rust-lang.org/t/unpoisoning-a-mutex/16521/3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use "the `WouldBlock` error" instead of "the error `WouldBlock`", etc.
|
|
Clarify error returns from Mutex::try_lock, RwLock::try_read,
RwLock::try_write to make it more obvious that both poisoning
and the lock being already locked are possible errors.
|
|
|
|
|
|
They now show the poison flag and use debug_non_exhaustive.
|
|
|
|
|
|
The (unsafe) Mutex from sys_common had a rather complicated interface.
You were supposed to call init() manually, unless you could guarantee it
was neither moved nor used reentrantly.
Calling `destroy()` was also optional, although it was unclear if 1)
resources might be leaked or not, and 2) if destroy() should only be
called when `init()` was called.
This allowed for a number of interesting (confusing?) different ways to
use this Mutex, all captured in a single type.
In practice, this type was only ever used in two ways:
1. As a static variable. In this case, neither init() nor destroy() are
called. The variable is never moved, and it is never used
reentrantly. It is only ever locked using the LockGuard, never with
raw_lock.
2. As a Boxed variable. In this case, both init() and destroy() are
called, it will be moved and possibly used reentrantly.
No other combinations are used anywhere in `std`.
This change simplifies things by splitting this Mutex type into
two types matching the two use cases: StaticMutex and MovableMutex.
The interface of both new types is now both safer and simpler. The first
one does not call nor expose init/destroy, and the second one calls
those automatically in its new() and Drop functions. Also, the locking
functions of MovableMutex are no longer unsafe.
|
|
|
|
Use Arc::clone and Rc::clone in documentation
This PR replaces uses of `x.clone()` by `Rc::clone(&x)` (or `Arc::clone(&x)`) to better match the documentation for those types.
@rustbot modify labels: T-doc
|
|
Also doing fmt inplace as requested.
|
|
|
|
|
|
|
