Re: Fix libunistring in MS-Windows locales

[Eli Zaretskii]

> From: Daiki Ueno <address@hidden>
> Cc: address@hidden,  address@hidden
> 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?