On Wed, 09 Oct 2013 17:27:16 +0200 [email protected] (Søren Sandmann) wrote:
> Siarhei Siamashka <[email protected]> writes: > > > On Wed, 09 Oct 2013 17:06:06 +0200 > > [email protected] (Søren Sandmann) wrote: > > > >> Andrea Canciani <[email protected]> writes: > >> > >> > Sorry, I didn't realize it beforehand, but I just noticed that > >> > thread-test > >> > fails on MacOS. > >> > This happens because it relies on the availability of OpenMP to have a > >> > thread-local state for the prng. > >> > Would it be ok to have each thread explicitly keep the state of its prng > >> > or > >> > is this another element that the test is supposed to be checking? > >> > >> It's not intended to test the thread-private-ness of the prng states, so > >> yes, the simplest fix seems to be to just explicitly keep a prng_t > >> for each thread. > > > > Would it really help to pass the test? The fast path cache is using the > > thread-local storage too. > > But the fast path cache is using the PIXMAN_DEFINE_THREAD_LOCAL macro > that uses pthread_setspecific() on Mac OS. I suppose it would make sense > to use that macro in thread_test as well, just to make sure it works. OK, this is a bit messy. The prng code is only compatible with OpenMP threads while the thread-test is using pthreads. It also fails with clang in Linux. Explicitly keeping a prng_t for each thread would be indeed a good solution. It also very likely is going to have a lower overhead. -- Best regards, Siarhei Siamashka _______________________________________________ Pixman mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pixman
