Locale change ideas

[Rich Felker <dalias@libc.org>]

Just some ideas I want to put in writing and put out for discussion:

Implementing a static all-C locale_t object (and, if we make C locale
byte-based, also an all-C.UTF-8 one) returned by newlocale when
possible. This would ensure that uses of newlocale "C" for robustness
against LC_NUMERIC radix points and such would be fail-safe and
high-performance. One caveat: freelocale needs to be aware of these
static locale objects so it doesn't try to free them, and newlocale
also needs to call calloc rather than modifying-in-place when using
them as a base.

Eliminating the messages_name field from the locale struct. I don't
like the way it's subject to data races. Even if changing locale out
from under other threads is not meaningful, it should not have data
races this bad. My thought is to intern a __locale_map object whenever
a new name is selected for LC_MESSAGES, even if the name does not map
to a locale file (now we intern only existant locales). When the
locale file does not exist, the map would just contain an empty/NOP mo
image and the requested name. Then (1) the object would not be
accessed until its permanent name is in place, and (2) switching
messages language names would inherit atomic semantics from the
handling of all other locale categories.

Handling non-synchronized reads of locale categories. The cat[]
pointers are updated atomically, but there's no barrier on the reading
side. This is okay and totally correct from an "I don't want
atrociously bad performance to support broken code" standpoint, but I
think we should take some effort to make sure it's safe. I don't mind
if a thread that hsan't synchronized with the changes to the locale
object doesn't see the latest settings, but I am worried about what
happenes when it reads the __locale_map objects that the cat[]
pointers point to. Is there a way to guarantee that if they see p,
they also see any stores to *p sequenced before the update of p by a
barrier? This is related to the nightmare that is consume-order, I
think.

Rich