only set a new random seed if _the last_ Generator gets destruct'ed #871
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In cases where multiple Generator instances might be created, a gc cycle collection run can trigger at any time, potentially removing "old" Generator instances, which then calls __destruct and thus seed, which reset the *global* mt_rand seed, impacting everyone else. If another, still live instance of Generator gets used after that, its output is no longer deterministic, since a new random seed was set.
krsriq
reviewed
Mar 19, 2024
src/Generator.php
Outdated
Comment on lines
564
to
566
| * In order top prevent resetting the seed while another Generator instance is still alive, we keep track of the | ||
| * total, global number of Generator being "active". Incremented in __construct, decremented in __destruct. | ||
| * This is necessary, because __destruct modified global state (`mt_srand`). |
There was a problem hiding this comment.
A couple of typos here:
Suggested change
| * In order top prevent resetting the seed while another Generator instance is still alive, we keep track of the | |
| * total, global number of Generator being "active". Incremented in __construct, decremented in __destruct. | |
| * This is necessary, because __destruct modified global state (`mt_srand`). | |
| * In order to prevent resetting the seed while another Generator instance is still alive, we keep track of the | |
| * total, global number of Generators being "active". Incremented in __construct, decremented in __destruct. | |
| * This is necessary, because __destruct modifies global state (`mt_srand`). |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 1 week if no further activity occurs. Thank you for your contributions. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the reason for this PR?
In cases where multiple Generator instances might be created, a gc cycle collection run can trigger at any time, potentially removing "old" Generator instances, which then calls __destruct and thus seed, which reset the global mt_rand seed, impacting everyone else.
If another, still live instance of Generator gets used after that, its output is no longer deterministic, since a new random seed was set.
Generator::seedinGenerator::__destructmay break determinism #870 )Author's checklist
Summary of changes
I added a new static class property to
Faker\Generatorwhich counts the number of currently existing Generator instances: It gets incremented in __construct, and decremented in __destruct. Only if this counter reaches 0 does __destruct also callseedto restore the system to a "properly random" state.Using a global counter is, imho, quite ugly, but since
Generator::seedalready modifies global state anyway I think its like fighting fire with fire.Other than that, I think its a quite minimal change that does not impact any other use of Faker. Cases that "properly" only ever use exactly one instance of the Generator will not see any difference in behaviour.
It's not a perfect solution by any means. But I think it is a reasonable one.
Review checklist
CHANGELOG.md