Can we have one generator to do it all (excepting reproducibility)? ThreadRng attempts to achieve this:

• It's fairly fast
• It only requires 320 bytes + overhead (Rc and thread_local) per thread
• It's unpredictable
• It has periodic reseeding

Put another way, there are reasons that this is sub-optimal:

• SmallRng is significantly faster (very roughly double the performance) and much smaller (32 bytes) while being good enough for many uses
• ThreadRng does not currently have forward secrecy. We could tack this on for approx 10-25% performance overhead.

Other limitations:

• ThreadRng does not have built-in fork or snapshot+resume protection. This will not change; see e.g. ThreadRng and StdRng after a snapshot or checkpoint restore: a sentence for the docs? #1843.

Plan

Strong + weak sources

ThreadRng has quite a few users, so I do not believe we should just abandon it. Instead, I propose:

• Re-add ReseedingRng not as a generic wrapper but as a concrete struct over ChaCha12 with periodic reseeding and fast erasure.
• Add StrongRng (name?) as a handle to a Mutex<ReseedingRng> in static memory (feature-gated, default off).
• Add SmallThreadRng as a thread-local SmallRng and maybe rand::fast_rng() to access it (feature-gated, default off).
• If possible, #[deprecate] the existing ThreadRng and methods after adding replacements before the next breaking release.

Note: the fast-erasure (forward secrecy) addition requires breaking changes to rand_core. The rest should be possible to add in a patch release. See: RustCrypto/stream-ciphers#578

Note: this is very much a tentative plan. Feedback welcome!

Alternatives

There is an alternative strong source: SysRng. This is slower than ThreadRng (potentially much much slower, depending on the platform) but (depending on the application) may still be sufficiently performant and does not have the same security limitations as ThreadRng.

There is an alternative where fast generation is required: make a local PRNG, e.g. using make_rng. Limitation: constructing and initializing the PRNG using a system seed will not be very fast, hence this is only really useful where a significant amount of data must be generated or the user passes this PRNG to multiple use-sites. I suspect this would be inconvenient for many games; on the other hand it is already a necessary step to achieve reproducibility.