In defense of lock poisoning in Rust

Re:In defense of lock poisoning in Rust by bheadmaster on Wednesday December 03, 2025 @03:22AM (#46131645)

As a Go programmer, I find it quite puzzling that Rust didn't handle panic edge cases as well as Go did with defer keyword. Defer executes at the end of a function, regardless of whether it returned or panic'd, so you can write safe mutex code just by doing something like:

    mutex.Lock()
    defer mutex.Unlock()

And if you need to unlock the mutex in one of multiple places, you can wrap it into a sync.Once.

There must be a reason Rust doesn't do something similar...

[ Parent | on HN ]

Re:In defense of lock poisoning in Rust by wahern on Wednesday December 03, 2025 @05:18AM (#46132716)

It does do something similar... and more. IIUC, when unwinding on panic Rust does unlock the mutex, but it also "poisons" it so that a subsequent attempt to lock will return an error. This is because on panic all the code protected by the mutex didn't get to run to completion, possibly leaving an inconsistent state. A poisoned mutex can be reset, though.

[ Parent | on HN ]

Re:In defense of lock poisoning in Rust by zidel on Wednesday December 03, 2025 @08:02AM (#46134014)

Rust handles this by automatically unlocking when the MutexGuard returned by lock() is dropped. The issue here is not that the mutex remains locked, but rather that the data protected by the mutex might be inconsistent (and the mutex unlocked) after a panic.

[ Parent | on HN ]

Re:In defense of lock poisoning in Rust by bheadmaster on Wednesday December 03, 2025 @08:34AM (#46134309)

Ah, so my understanding of the problem was wrong.

Thanks for the clarification.

[ Parent | on HN ]