Skip to main content

## Module lock

Source
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§

MutexSafe
  Poison-tolerant locking for `std::sync::Mutex`.
RwLockSafe
  Poison-tolerant locking for `std::sync::RwLock`.