Consider replacing parking_lot::RwLock with the lock from the standard library

[yorickpeterse]

This type is used at

inkwell/src/targets.rs

Line 141 in 41d335b

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]

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]

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

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

[yorickpeterse]

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

Forgot to mention - feel free to PR

[yorickpeterse]

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