Lock poisoning in Rust detects when a thread panics while holding a mutex, preventing silent data corruption. When a panic occurs during a critical section, the mutex is marked poisoned, causing subsequent lock attempts to fail. This mechanism is crucial because panics can leave shared data in inconsistent states. The author argues against proposals to remove poisoning by default, advocating instead for making lock() automatically panic on poison while maintaining safety. The piece explores how unexpected cancellations—both from panics and async future cancellations—can violate mutex invariants, and why detection through poisoning is more important than recovery.
Table of contents
What is poisoning? #Unexpected cancellations #Do panics in critical sections always cause invariant violations? #Where else can panics cause invariant violations? #Separating mutexes from poisoning? #What about parking_lot mutexes? #Just ship with panic = 'abort' ? #Typing in .lock().unwrap() is annoying #Conclusion #Appendix: Mutexes and future cancellations #1 Comment
Sort: