3 ms·
A panic in single-threaded, non-parallel code will either terminate the program or be recovered cleanly, so the potential for side effects to be silently observ
by zozbot234 1y ago
A panic in single-threaded, non-parallel code will either terminate the program or be recovered cleanly, so the potential for side effects to be silently observed in a way that breaks invariants is unique to Mutex<>. This is the reason for mutex poisoning,
- simonask 1y agoI fail to see that there is any material difference. Whether you catch-unwind within a single thread or in a separate thread such that the panic can be resumed on join makes zero difference. Heck, you can have Drop impls observing the state while unwinding. A true panic-safe data structure requires serious thought, and mutex poisoning does nothing here - it is neither necessary nor sufficient.
- JoshTriplett 1y agoThis is exactly the problem. Poison is enough to be painful but not enough to fully solve the problem. > Heck, you can have Drop impls observing the state while unwinding. Yeah, this is really painful and regularly forgotten. And one reason it'd be nice to not have unwinding.
- dap 1y agoThis is a false dichotomy. Not every technique needs to work in all cases in order to be useful. This seems analogous to arguing that because seat belts don't save the lives of all people involved in car crashes, and they're kind of annoying, then they shouldn't be factory-standard.
- simonask 1y agoThis is a case of a feature that is actively harmful for the things it tries to prevent, because it increases the risk in practice of panics "spreading" throughout a system, even after the programmer thought she had finished handling it, and because it gives a false impression what kind of guarantee you actually have.