Re: Fix libunistring in MS-Windows locales

[Eli Zaretskii]

> From: Daiki Ueno <address@hidden>
> Cc: address@hidden,  address@hidden
> Date: Thu, 17 Jul 2014 12:59:59 +0900
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> By the way, isn't there a minor race in gl_locale_name_thread, since it
> >> depends on a global variable found_lcid?
> >
> > Yes.  (It is not a problem for Guile, since Guile built with threads
> > on Windows is severely broken, so the only way of having a useful
> > Guile on Windows is to build it without threads.)  Suggestions for
> > fixing that are welcome.  Maybe just use the '__thread' qualifier for
> > that variable?
> 
> I'm not familiar with Windows TLS support, but '__thread' seems to be
> compiler specific.

Do we care for any Windows compilers except GCC?

> Gnulib has glthread/tls but I'm not sure if it is worth adding
> another dependency to localename.c (which is also shared with
> libintl...) for this specific issue.

It isn't worth it (and AFAICS, that module doesn't have a Windows
implementation anyway).

> Maybe just lock around the use?

I don't like locking for no good reason.

I could use explicit Windows API calls (TlsGetValue etc.) instead of
GCC-specific features, if that is more acceptable.