<table><tr><td style="">tfry created this revision.<br />Restricted Application added a project: Frameworks.<br />Restricted Application added a subscriber: Frameworks.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D5966" rel="noreferrer">View Revision</a></tr></table><br /><div><strong>REVISION SUMMARY</strong><div><p>Consider the following scenario: Thread A calls KRandom::random(), for the first time.<br />
It will now go through a (relatively) expensive procedure to seed the RNG. Note that before<br />
this patch, "init" is set to true long _before_ the actual call to qsrand().<br />
Now, thread B calls KRandom::random() in this sensitive time window. Since it finds "init"<br />
to be true, it will skip over the expensive initialization, and be very likely to arrive at<br />
qrand(), before thread A had a chance to call qsrand().</p>

<p>This patch is the simplest possible solution: Making sure init is set, _after_ the seed was<br />
really initialized. This does not prevent init races, but the worst case scenario is now, that<br />
several threads are each going through the seeding. A more elaborate solution would be to<br />
add mutex-protection during initialization.</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R244 KCoreAddons</div></div></div><br /><div><strong>BRANCH</strong><div><div>master</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D5966" rel="noreferrer">https://phabricator.kde.org/D5966</a></div></div><br /><div><strong>AFFECTED FILES</strong><div><div>src/lib/randomness/krandom.cpp</div></div></div><br /><div><strong>To: </strong>tfry, dfaure<br /><strong>Cc: </strong>tfry, rjvbb, Frameworks<br /></div>