Shall rand be a dev-dependency in parking_lot_core, like in parking_lot?

[vi]

Just connecting parking_lot brings entire chunk of rand_* entries into cargo tree.

[Amanieu]

This is by design, some randomness is used as part of the fairness mechanism in parking_lot_core.

[matklad]

Note that the future version of rand plans to prune dependencies a bit: rust-random/rand#715

[faern]

Could we not swap the rand dependency for rand_pcg? parking_lot currently only uses SmallRng which in the background is just rand_pcg::Pcg64Mcg or rand_pcg::Pcg32 depending on architecture.

[matklad]

Another option, if we don't need super-high-quality randomness, is to just vendor xor-shift RNG, like the [T]::sort does:

https://github.com/rust-lang/rust/blob/c28084ac16af4ab594b6860958df140e7c876a13/src/libcore/slice/sort.rs#L486-L493

[faern]

If we include a simple PRNG in parking_lot itself we get the benefit of being able to use it when parking_lot acts as the locking implementation inside libstd (#119) and we get less conditional compilation and a bit more randomness to the fairness in libstd.

[Amanieu]

Vendoring a simple PRNG sounds like a good idea that will solve multiple problems.

[faern]

I copied the linked PRNG from libstd and took a stab at implementing this. See #144. I have not evaluated the quality of that PRNG or anything. But this compiles and the tests pass.

[vi]

Vendoring a simple PRNG

What about vendoring a simple PRNG into Rust's libcore? It doesn't look OK if everybody around starts vendoring a simple PRNG.

[Amanieu]

No, crates that need a PRNG should just use the rand crate. We only need to vendor one here because parking_lot is intended to be used as part of libstd, which cannoy depend on other crates.

[matklad]

It might be worthwhile to do a release of parking_lot without rand: rand recieved a major version bump recently, so published parking_lot now depends on outdated version.

[Amanieu]

I just published 0.8.1 without rand.