Conversation
|
Preview available at https://egui-pr-preview.github.io/pr/7497-lucasremove-deadlock-detection |
| #[cfg(not(target_arch = "wasm32"))] | ||
| #[cfg(feature = "deadlock_detection")] | ||
| #[cfg(test)] | ||
| mod tests_rwlock { | ||
| #![allow(clippy::disallowed_methods)] // Ok for tests |
There was a problem hiding this comment.
The #[should_panic] tests still work, but now take 30s to complete.
Should I
- remove the tests?
- lower the
DEADLOCK_DURATIONto 10s? - keep it as is
I think I prefer setting DEADLOCK_DURATION to 10s, I think it should be fine considering no locks should be held longer than a frame
There was a problem hiding this comment.
I agree - 10s should be good enough for anyone
|
It's worth noting what the old deadlock detector was good for, which was re-entrant locking of the same mutex on the same thread. In that case the detector would print the callstack of both |
| #[cfg(not(target_arch = "wasm32"))] | ||
| #[cfg(feature = "deadlock_detection")] | ||
| #[cfg(test)] | ||
| mod tests_rwlock { | ||
| #![allow(clippy::disallowed_methods)] // Ok for tests |
There was a problem hiding this comment.
I agree - 10s should be good enough for anyone
* related #7494 Removes the `deadlock_detection` feature, since we now have a more primitive panic-after-30s deadlock detection which works well enough and even detects kinds of deadlocks that the `deadlock_detection` feature never supported.
* related emilk#7494 Removes the `deadlock_detection` feature, since we now have a more primitive panic-after-30s deadlock detection which works well enough and even detects kinds of deadlocks that the `deadlock_detection` feature never supported.
2 participants
ImageLoader,FileLoader,EhttpLoader#7494Removes the
deadlock_detectionfeature, since we now have a more primitive panic-after-30s deadlock detection which works well enough and even detects kinds of deadlocks that thedeadlock_detectionfeature never supported.