Remove automatic (delayed) reseed-on-fork #1379
Conversation
The only thing these achieve is a different error message
| /// (every 64 kiB — see [`ReseedingRng`] documentation for details). | ||
| /// | ||
| /// `ThreadRng` is not automatically reseeded on fork. It is recommended to | ||
| /// explicitly call [`ThreadRng::reseed`] immediately after a fork, for example: |
There was a problem hiding this comment.
It also could be worth to mention pthread_atfork as a potential approach for doing this.
UPD: Further in the docs fork handlers are discussed and it's indeed not safe to mess with ThreadRng state in fork handlers, including child ones.
There was a problem hiding this comment.
Technically, it might be okay: ThreadRng methods should not be called at the time fork() happens. But I don't see the need to advertise this beyond what is already said.
|
Nightly builds fail due to zerocopy (google/zerocopy#844). Probably a good idea to leave this PR open a little longer anyway in case anyone has concerns about the removal of automatic reseed-on-fork. |
|
No further comments, so I'll merge now. In case @tarcieri @briansmith or others have concerns, we still have the option to revert before 0.9. |
* benches/generators.rs: standardize thread_rng benchmarks * Remove cfgs from examples * Remove ReadRng * Add ThreadRng::reseed and doc to use * Remove fork protection from ReseedingRng; remove libc dep * Enable ReseedingRng without std * Move ReseedingRng up; remove module rand::rngs::adapter
See also #1362 #1377
CC @thomcc
Remove integrated fork protection.
Add
ThreadRng::reseedand doc to suggest calling this on fork.Make
ReseedingRng::reseedalso clear the random value cache.