Re: Per thread locales

[christos%astron.com@localhost (Christos Zoulas)]

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örg 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?

>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);
}

>
>> 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.

christos