Re: Locale change ideas

[Rich Felker <dalias@libc.org>]

On Tue, May 26, 2015 at 11:12:08PM -0400, Rich Felker wrote:
> 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

Done; see commit aeeac9ca5490d7d90fe061ab72da446c01ddf746.

> Eliminating the messages_name field from the locale struct. I don't

Done; see commit 61a3364d246e72b903da8b76c2e27a225a51351e. This also
made handling of LC_CTYPE and LC_NUMERIC uniform with the rest of the
categories rather than special-cased.

> Handling non-synchronized reads of locale categories. The cat[]

This still needs to be reviewed. There is a barrier (due to UNLOCK)
between the writes to a new __locale_map object (which is immutable
once it's written) and storing that object's address anywhere. It's
not clear to me whether any further synchronization is necessary. It's
not needed for archs with strong memory order, and I'm fairly sure it
should not be needed for archs with dependency ordering, but I'm not
sure if this covers everything. The case to worry about is where the
new object gets allocated in memory that happens to already be cached
(because it was used then freed) by another thread, and whether that
thread might read stale data after obtainin/reading the pointer to it.
Anyone know if this is a real possibility, and if there are good
mitigations without putting a barrier at the point of read? (This is
surely related to the consume-order stuff everybody is so fond of
discussing and arguing about these days... :)

Rich