[Pixman] [PATCH 2/2] test: Add new thread-test program

[Andrea Canciani]

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 <
siarhei.siamashka at gmail.com> wrote:

> On Wed, 09 Oct 2013 17:27:16 +0200
> sandmann at cs.au.dk (Søren Sandmann) wrote:
>
> > Siarhei Siamashka <siarhei.siamashka at gmail.com> writes:
> >
> > > On Wed, 09 Oct 2013 17:06:06 +0200
> > > sandmann at cs.au.dk (Søren Sandmann) wrote:
> > >
> > >> Andrea Canciani <ranma42 at gmail.com> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/pixman/attachments/20131009/60f5b1ca/attachment.html>