Avoid thread::panicking() in non-poisoning methods of Mutex and RwLock
#97924
Conversation
…RwLock` `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.
|
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
rustbot
added
the
T-libs
|
r? @kennytm (rust-highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
r? rust-lang/libs |
|
@bors r+ rollup=never |
|
📌 Commit 34895de has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (ec21d7e): comparison url. Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression Footnotes |
Mutex::lock()andRwLock::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 thepoison flag alone.
That check is a bit of a waste for methods that never set the poison
flag though, namely
get_mut(),into_inner(), andRwLock::read().These use-cases are now split to avoid that unnecessary call.