Re: C++ io, thread safety, and setlocale

[John Ruttenberg <rutt at chezrutt dot com>]

Loren James Rittle:
> Hi,
> 
> > Pehaps this is a FAQ, but I couldn't find anything.
> 
> You could find more details about this in section 5.6 of
> libstdc++-v3/docs/html/faq/index.html .  Note well the exact words
> where we weasel out in various cases; mainly involving unknown libc
> implementation.  One could conceive of a thread implementation where
> setlocale acted on a per-thread basis but I'd agree in my experience
> this is unlikely.
> 

OK, I read this closely, but I still don't understand.  How can it be safe for
standard library calls to use setlocale in this way?  Isn't there a per thread
locale that you should use to make this safe?  (Not that I actually know
anything about this; I'm just trying to fight a fire.)  What do you do with
glibc or on solaris that makes those situations work (I think they do; our
application has been running in those environments for a long time without
experiencing these problems.)

> > How can this be thread safe without some locking of some sort?
> 
> Even if that particular call (or pair of calls to set and then reset)
> was wrapped with a lock, it doesn't really improve the situation since
> your user-level code may have called setlocale directly or other IO
> calls that indirectly use the global locale settings.  At the moment,
> the C++ library code base is favoring locale support over thread
> support in the generic IO/locale code.  I believe that for people
> using the "C" locale, we should try harder to be thread-safe in all IO
> cases (by skipping the setlocale call); however with the unconditional
> calls to setlocale; we can't be at the moment.
> 

Can I build the library in some way that will avoid the locale support in
favor of thread support.