-
Notifications
You must be signed in to change notification settings - Fork 239
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
Consider replacing parking_lot::RwLock with the lock from the standard library #419
Comments
The reason for using parking lot here is that we don't care about poisoning, and wouldn't want another thread to crash (it seems idiomatic to just unwrap the std Mutex/RwLock) on poison, nor do we really want to add extra err handling for that case |
@TheDan64 The only place this lock is used in various Even if it gets poisoned it might not matter, as I believe you can basically just ignore that using let mut guard = lock.write().unwrap_or_else(|e| e.into_inner());
*guard = ...; So to summarise: if poisoning is the sole reason for using parking_lot, then I think there are easy enough ways to work around that, without the need for extra dependencies 😃 |
We also use it for the global Context which a user could cause to poison |
@TheDan64 In that case the snippet I shared should be sufficient to deal with the rare case that a process panics, but the developer wants different threads using Inkwell to continue running. |
Forgot to mention - feel free to PR |
@TheDan64 I'll take a look at it this week 😄 |
Historically parking_lot's locking types performed better, but since a few Rust releases ago the types provided by the standard library perform well enough. Replacing parking_lot also reduces the number of dependencies. See #419 for more details.
This type is used at
inkwell/src/targets.rs
Line 141 in 41d335b
If replacing parking_lot is fine I'll happily set up a pull request 😄
The text was updated successfully, but these errors were encountered: