On further investigation, I see that qsrand() would probably have to be called for each thread, in any case. So that would mean keeping track of initialization state in a QThreadStorage<bool>?

I was going to reflect that it would be better to set init in an atomic operation, but:

In D5966#111735, @tfry wrote:

On further investigation, I see that qsrand() would probably have to be called for each thread, in any case.

From the qsrand() documentation:
"The sequence of random numbers generated is deterministic per thread. For example, if two threads call qsrand(1) and subsequently call qrand(), the threads will get the same random number sequence."

That indeed probably means that if only thread 1 calls qsrand(), thread 2 will get the default, unseeded sequence.

So that would mean keeping track of initialization state in a QThreadStorage<bool>?

Or a simple QSet containing the thread ID, whichever is cheapest?

Would it be better to use QThreadStorage<bool> (to record if the thread has been seeded) instead of a QSet? It would allow us to more easily adopt C++11's thread_local once we remove support for older compilers. I also looked into whether we could adopt the higher-quality RNGs that should be available in C++11, but getting them seeded is apparently very difficult to do without introducing errors.

Also, I'd recommend using quintptr instead of intptr_t in the reinterpret_cast, as that seems more accurate for the semantics of XOR. The shift to XOR is a great idea though.

Using QSet was my suggestion, if cheaper than QThreadStorage - something I didn't check, but I also didn't verify if QSet::insert is thread-safe.

About C++11: since when exactly does Qt require C++11 again?

In D5966#111878, @rjvbb wrote:

but I also didn't verify if QSet::insert is thread-safe.

Ouch, you're right, it isn't. QThreadStorage it shall be, then (until we can use thread_local). That also handles thread-destruction, properly.

The changeset is fine to go in (once the duplicated semicolon is fixed).

As for C++11, I'm not aware that Qt requires C++11 as a blanket policy. Instead they require specific compilers, and then we can use the C++11 features supported by that compiler.

According to the Qt documentation, Qt 5.8 is the first Qt release to require at least GCC 4.8 across the board, on configurations using GCC. I believe that was the first GCC where thread_local is fully supported. Note that we do try to support MS Windows though, and MSVC as distributed with VS 2013 is the minimum requirement for both Qt 5.8 and current Qt development. But MSVC doesn't fully support thread_local until VS 2015. So it will probably be at least another couple of years before we can rely on that feature to be available.

I have no official reference for Qt requiring C++11, but I'm pretty sure I've seen the remark made on a mailing list or one of their code review tickets. I would have guessed that was with 5.7 but it can just as well be 5.8 and later. A GCC >= 4.8 *probably* corresponds to "we need complete enough C++11".

Supporting MSVC is a PITA: https://phabricator.kde.org/D5865

No - not with this syntax. See the stackoverflow discussion I posted, or https://stackoverflow.com/questions/31645309/can-i-use-a-c-variable-length-array-in-c03-and-c11?rq=1