Skip to content
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

Closed
yorickpeterse opened this issue May 13, 2023 · 6 comments · Fixed by #442
Closed
Labels
Milestone

Comments

@yorickpeterse
Copy link
Contributor

This type is used at

static TARGET_LOCK: Lazy<RwLock<()>> = Lazy::new(|| RwLock::new(()));
. For such a simple scenario, the RwLock type from the standard library should be more than sufficient. In addition, it can reduce the number of dependencies (including indirect ones) by up to 8 dependencies, depending a bit on which ones are already in your dependency graph (or not). This in turn can speed up compile times a bit, but it's mostly because using parking_lot for just this scenario is overkill.

If replacing parking_lot is fine I'll happily set up a pull request 😄

@TheDan64
Copy link
Owner

TheDan64 commented May 13, 2023

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

@yorickpeterse
Copy link
Contributor Author

@TheDan64 The only place this lock is used in various Target method. The lock itself is private, and only acquired briefly when calling LLVM's C functions. As far as I can tell from looking at the code, there's no way Inkwell can actually run into a panic while holding a lock. As such I don't see a way of the lock ever getting poisoned.

Even if it gets poisoned it might not matter, as I believe you can basically just ignore that using PoisonError::into_error, meaning you'd end up with something like this:

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 😃

@TheDan64
Copy link
Owner

TheDan64 commented May 13, 2023

We also use it for the global Context which a user could cause to poison

@yorickpeterse
Copy link
Contributor Author

@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.

@TheDan64 TheDan64 added this to the 0.3.0 milestone Sep 4, 2023
@TheDan64
Copy link
Owner

TheDan64 commented Sep 4, 2023

Forgot to mention - feel free to PR

@yorickpeterse
Copy link
Contributor Author

@TheDan64 I'll take a look at it this week 😄

TheDan64 pushed a commit that referenced this issue Sep 14, 2023
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.
@TheDan64 TheDan64 modified the milestones: 0.5.0, 0.3.0 Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants