Reading through the summary, everything looks impressive. Are there any known cons of parking_lot ?
If you are writing library crates, then its send_guard
feature will with high probability affect the public API of your crate unless you take measures to prevent that like Tokio does in this file.
Parking lot doesn't support poisoned locks, it unlocks when unwinding from a panic. So panic at the wrong time may break an invariant the lock should be protecting. If you're using panic=abort then it shouldn't be cause any problems since it won't unwind.
Regarding poisoning, this can be fixed manually, when needed, as I learned in another thread:
Dumb question: can we add poisoning just by adding a 'poisoned: bool' which we set to true after lock() and set to false right before unlock() ?
Yes, I think that's what @kpreid said here:
[…] so the design choice was made to leave it out since an application can add its own poison flag if it likes.
parking_lot is somewhat churn-prone -- it has a fair amount of versions, and it's quite probable that any given Cargo.lock includes several parking lots. Also, note that stdlib's implementation of mutexes on Linux was improved a lot in Replace Linux Mutex and Condvar with futex based ones. by m-ou-se · Pull Request #95035 · rust-lang/rust · GitHub, so parking lot comparative advantage will be smaller.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.