> From: Daiki Ueno <u...@gnu.org> > Cc: egg...@cs.ucla.edu, bug-gnulib@gnu.org > Date: Thu, 17 Jul 2014 12:59:59 +0900 > > Eli Zaretskii <e...@gnu.org> 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.
