I just sent a wannabe patch for this issue. I did not test on clang/linux, but I expect it to work in that environment as well. Can you confirm this?
TY Andrea On Wed, Oct 9, 2013 at 5:46 PM, Siarhei Siamashka < [email protected]> wrote: > 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
