New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: handle std Mutex
poisoning in a shim
#2872
chore: handle std Mutex
poisoning in a shim
#2872
Conversation
6a32314
to
b9bbd46
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks 👍
Looks like there is a conflict. |
As tokio does not rely on poisoning, we can avoid always unwrapping when locking by handling the `PoisonError` in the Mutex shim. Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
Signed-off-by: Zahari Dichev <zaharidichev@gmail.com>
5a7a6a1
to
7981985
Compare
resolved conflicts |
#[inline] | ||
pub(crate) fn lock(&self) -> MutexGuard<'_, T> { | ||
self.0.lock().unwrap() | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't really seem correct? Shouldn't it use into_inner
? Or maybe it's good to panic on poisoning in loom tests?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Poisoning in loom is good because we should never hit it.
Motivation
As tokio does not rely on poisoning, we can
avoid always unwrapping when locking by handling
the
PoisonError
in the Mutex shim.Solution
Provide a wrapper around std::sync::Mutex that uses
PoisonError::into_inner
to ignore the poisoning aspectsof the std api.
Fix #2867
Signed-off-by: Zahari Dichev zaharidichev@gmail.com