Notes On Lock Poisoning

Midori error model makes sharp distinction between two kinds of errors:

• bugs in the program, like indexing an array with -92

• error conditions in programs' environment (reading a file which doesn’t exist)

In Rust, those correspond to panics and Results. It’s important to not mix the two.

std I think sadly does mix them in sync API. The following APIs convert panics to recoverable results:

• Mutex::lock

• thread::JoinHandle::join

• mpsc::Sender::send

All those APIs return a Result when the other thread panicked. These leads to people using ? with these methods, using recoverable error handling for bugs in the program.

In my mind, a better design would be to make those API panic by default. Sometimes synchronization point also happen to be failure isolation boundaries. More verbose result-returning catching_lock, catching_join, catching_send would work for those special cases.

If std::Mutex did implement lock poisoning, but the lock method returned a LockGuard<T>, rather than Result<LockGuard<T>, PoisonError>, then we wouldn’t be discussing poisoning in the rust book, in every mutex example, and wouldn’t consider changing the status quo. At the same time, we’d preserve "safer" semantics of lock poisoning.

There’s an additional consideration here. In a single-threaded program, panic propagation is linear. One panic is unwound past a sequence of frames. If we get the second panic in some Drop, the result is process aborting.

In a multi-threaded program, the stack is tree-shaped. What should happen if one of the three parallel threads panics? I believe the right semantics here is that siblings are cancelled, and then the panic is propagated to the parent. How to implement cancellation is an open question. If two children panic, we should propagate a pair of panics.