In defense of lock poisoning in Rust
9 days ago
- #Rust
- #Concurrency
- #Safety
- Lock poisoning in Rust is a mechanism to detect and handle panics within critical sections to prevent system corruption.
- Unexpected cancellations, such as panics or async future cancellations, can violate mutex invariants, leading to logical corruption.
- Rust's mutex poisoning marks a mutex as poisoned if a panic occurs during a critical section, signaling potential corruption.
- The proposal to make mutexes non-poisoning by default risks undetected corruption, as silent unlocking on panic hides errors.
- A suggested improvement is to make `lock()` automatically panic if poisoned, reducing syntax noise while maintaining safety.
- Non-poisoning mutexes have limited use cases, such as metrics or logging, but should not be the default due to safety risks.
- The `Poison<T>` wrapper could generalize poisoning beyond mutexes, offering flexibility without compromising safety by default.