Expand description
Poison-tolerant locking helpers.
std::sync::Mutex and RwLock become poisoned if a thread panics while
holding the guard. After that, every .lock().unwrap() / .read().unwrap()
/ .write().unwrap() panics as well — so a single failure can cascade into
an unrecoverable crash. That is a real risk for stateful subsystems like the
player, whose locks are touched from many background threads (the MPV event
loop, sleep/autoplay timers, JNI callbacks, the session poller).
These extension traits recover the guard from a poisoned lock instead of panicking. The data behind a poisoned lock may be in an unexpected state, but for this application’s state (queues, settings, flags) recovering and continuing is far preferable to taking down playback entirely.
Use lock_safe() / read_safe() / write_safe() in place of
.lock().unwrap() / .read().unwrap() / .write().unwrap().
Note: these apply only to std::sync primitives. tokio::sync::Mutex does
not poison, so async code keeps using .lock().await unchanged.
Traits§
- Mutex
Safe - Poison-tolerant locking for
std::sync::Mutex. - RwLock
Safe - Poison-tolerant locking for
std::sync::RwLock.