Re: Per thread locales

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Tue, Dec 29, 2015 at 01:16:11AM +0000, Christos Zoulas wrote:
> In article <20151229003516.GF26642%britannica.bec.de@localhost>,
> Joerg Sonnenberger  <joerg%britannica.bec.de@localhost> wrote:
> >On Mon, Dec 28, 2015 at 01:16:56PM +0100, Martin Husemann wrote:
> >> IIUC J�strongly prefers to fix all locale sensitiv calls to use variants
> >> explicitly passing the locale (which is most simple for "C").
> >
> >Correct. The problem with uselocale() is two fold:
> >(1) It requires ABI breaks.
> >(2) It just recreates the problems of interactions between different
> >components in a multithreaded binary from the thread level to the DSO
> >level.
> 
> Isn't this a result of the current locale design?

If anything, it is a result of the implementation choices made years
ago. uselocale() fundamentally can't be retrofitted into the way common
implementations e.g. of the ctype macros work.

> >There is a good reason why the C++ locale support doesn't use
> >per-thread locales. They are still a pretty stupid idea.
> 
> Yes, what's the alternative?
> 
> oldlocale = setlocale(newlocale);
> if (oldlocale) {
> 	copylocale = strdup(oldlocale);
> 	if (copylocale == NULL)
> 		setlocale(oldlocale);
> } else
> 	copylocale = NULL;
> 		
> ...do stuff with the new locale...
> 
> if (copylocale) {
> 	setlocale(copylocale);
> 	free(copylocale);
> }

Create the locale you need with newlocale and pass it to the locale
sentive functions you want to use. No global state needed and unlike
uselocale, we can even remove all the data afterwards. If you just want
to use the C locale, there is a predefined macro to get you that. On
FreeBSD/OSX, NULL as locale serves the same purpose.

> >
> >> However, this is not always trivial (when the code uses lots of deeply nested
> >> library code) so patches are hard to verify and even harder to upstream.
> >
> >I contest that. So far, the majority of the code wanting to use
> >uselocale always wanted the "C" locale. That's an audit of the locale
> >sensitive code and not so much a question of nesting.
> 
> Yes, you need to use it to temporary switch to the "C" locale and
> then put if back to what it was (for example if you want to use
> regex code that does not support other locales; another thing NetBSD
> does not support). It is important to only affect the current thread
> because you don't know what the other threads might be doing; or
> even if you are multithreaded at that point.

Regex support is part of collation -- in fact, the primary difficult
part. My point here is there is nothing like "affect only the current
thread" if you actually tell the functions explicitly what locale to
use. There is no shared global state that has to be updated. That's why
it is so friendly to both multi-threading and modularisation.

Joerg