Agreed, this doesn't look safe. Since the fix should be straightforward, would you like to make a PR? (Update the CHANGELOG too.)

Using compare_and_swap would allow: thread 1 calls ReseedRng::new and runs until just after thr cmpxchg; thread 2 calls ReseedRng::new,thinks it is initialized returns and spawns new process; thread 1 continues running.

Using std::sync::Once should fix this.

@bjorn3 agreed. Unfortunately Once is only available in std. This leaves us with three choices:

1. Restrict ReseedingRng (and the whole adapter module) to #[cfg(feature="std")]. Since this is likely not of use in no_std and thread_rng is already resticted to std this is probably the best choice, however it necessitates a breaking release of Rand.
2. Only call the fork handler when on Unix and cfg(feature = "std"). (This combination doesn't technically need to exist, but thanks to the way no_std works is still a valid compile target, thus we shouldn't break it.)
3. Implement Once ourselves with a spin-lock. This is the worst option IMO.

Option 2 seems best, because it is not a breaking change.

What about using spin::Once?

My preference is still option 1. @BurtonQin did you encounter this bug in action or find it through analysis? I'm wondering how easy it is to hit in practice (and how much to care about a quick fix and backports).

Through analysis.

My preference is still option 1. @BurtonQin did you encounter this bug in action or find it through analysis? I'm wondering how easy it is to hit in practice (and how much to care about a quick fix and backports).

Then I suggest we implement (2) now and (1) for Rand 0.8.