-
Notifications
You must be signed in to change notification settings - Fork 940
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
Remove parking_lot
dependency
#2423
Conversation
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 looks good to me; I'll always support removing a dependency that's been obsoleted by the standard library.
@@ -56,7 +56,7 @@ pub type XlibErrorHook = | |||
pub fn register_xlib_error_hook(hook: XlibErrorHook) { | |||
// Append new hook. | |||
unsafe { | |||
XLIB_ERROR_HOOKS.lock().push(hook); | |||
XLIB_ERROR_HOOKS.lock().unwrap().push(hook); |
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.
While this is entirely fine, I'd suggest having a macro like this somewhere in the crate:
macro_rules! lock {
($mutex: expr) => {{
match ($mutex).lock() {
Ok(guard) => guard,
Err(err) => {
log::warn!("Mutex is poisoned: {:?}", &err);
err.into_inner()
}
}
}}
}
And instead calling it like this:
lock!(XLIB_ERROR_HOOKS).push(hook);
This ensures two things:
- A poisoned lock won't blow up the entire system.
- If we decide to switch to another mutex scheme, for some reason, we can easily adjust
lock!
to fit our use case.
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.
I went with unwrap
because it's what's used in the other backends, and I'm not at all sure how to handle mutex poisoning
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.
Hmm, I guess I should add it in a separate PR then...
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.
That would be nice, please do!
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.
Great! I'll wait until after this PR is merged, so I can make a macro that works across the entire crate.
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.
Hey @notgull, this PR has been merged, so if you want to make this change, now you have the opportunity!
1d42aa2
to
49da6ff
Compare
5dd1bd2
to
9095ed4
Compare
ae8b967
to
19ba050
Compare
19ba050
to
e8531f3
Compare
Fixes #650.
std
'sMutex
has recently improved a lot, so there's not really a performance argument for keeping i any more. Also means we won't have to use the samewindows-sys
version asparking_lot
Dependency tree (Windows):
Dependency tree (X11):
CHANGELOG.md
if knowledge of this change could be valuable to users