[Pixman] [cairo] Problem in pthread-specific thread-local storage macros in pixman?

[Soeren Sandmann]

Tor Lillqvist <tml at iki.fi> writes:

> > A related question: Is there any support in the Windows versions of
> > GCC for either __thread or __declspec(thread)?
> 
> There is support for __thread (it gets recognized by the configure
> script), but I strongly suspect it might be broken.
> 
> I think I would prefer to just use explicit code, as in the pthread
> case. In fact, I was just hacking on that last weekend. Below is what
> I came up with before abandoning it... I.e. this is not really tested
> that well, as the thread-local storage is used, if I understood
> correctly, only when SSE2 is used, and as seen in another thread, SSE2
> intrinsics are broken in MinGW, so I disable it anyway currently...

The thread local storage is used for all fast paths, including the
plain old C ones, so it needs to work for pixman to work.

> This looks more complex than I like. The complexity comes mostly from
> the way the equivalent of pthread_once() is implemented; I got this
> idea from http://stackoverflow.com/questions/631879/library-initialization-pthread-once-in-win32-implementation
> .
> 
> Also, not being able to just #include <windows.h> is a pain. (That's
> the reason for the !defined(__WIN64); on 64-bit Windows the Win32 API
> declarations would be slightly different.)
> 
> This has to be before the check for if
> defined(TOOLCHAIN_SUPPORTS__THREAD), as that gets set for MinGW, too.
> 
> #if defined(__MINGW32__) && !defined(__WIN64)
> 
> /* We can't include <windows.h> as it causes carious clashes with
>  * identifiers in pixman, sigh. So just declare the functions we need
>  * here.
>  */

Which identifiers does it clash with? Maybe we can just rename the
pixman ones. We'll likely need to use the Interlocked functions in
various other places when we introduce more threading support.



Soren