> From: Daiki Ueno <u...@gnu.org>
> Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org
> Date: Fri, 18 Jul 2014 16:06:11 +0900
>
> FWIW I just tried myself (on wine, though) and it seems to work with:
>
> - GCC 4.8.3 (Fedora mingw64-gcc package, cross compiling)
> - GCC 4.7.2 (mingw-w32-bin_i686-mingw_20111219, self compiling)
>
> So, I guess it is OK to use __thread, though other 3 static variables
> (lname, last_lcid, and last_locale) would also need the same care.
Thanks.
Googling suggests that:
. __thread works as expected in MinGW GCC since version 4.5.0
. DLLs that use __thread (a.k.a. "implicit TLS") cannot be safely
loaded at run time, using LoadLibrary, on Windows versions before
Vista, they can only be loaded at program startup time (IOW, the
corresponding -lLIBRARY switch should be passed on the link
command line)
. DLLs that need to be able to support LoadLibrary on Windows XP and
older need to use explicit TLS API functions, which requires a
call to TlsAlloc in the DllMain function, another complication
Given the above, is it OK to use __thread and live with the
limitations? Or maybe we should simply go back to your idea of
locking, e.g., by using EnterCriticalSection and LeaveCriticalSection?
