Re: workaround against broken duplocale

[Joerg Sonnenberger]

On Tue, Aug 15, 2017 at 11:39:38PM +0200, Bruno Haible wrote:
> Hi Jörg,
> 
> Joerg Sonnenberger wrote:
> > uselocale() is fundamentally broken from a design perspective. It can't
> > be implemented without breaking ABIs.
> 
> Well, glibc did not break ABIs when it introduced uselocale() in 2002.
> If you have not exposed too many internals of the locale set by setlocale(),
> you shouldn't have any problems. And you have the __RENAME macro, to cope
> with these cases.

I don't know how glibc implemented e.g. ctype.h before. The classic way
to do it is providing a global masking table and that can't be switched
to support uselocale() without breaking the ABI or introducing wonderful
inconsistencies. The alternatives all depend on lying to the compiler or
taking a significant performance hit. The current glibc implementation
falls into the former category.

> > It breaks expectations of existing applications in funny ways
> 
> I would say, it breaks expectations of programmers who have not yet gotten
> familiar with the API. But existing applications - that do not invoke
> uselocale() - run without modifications and without change in behaviour.

This is not true. Before uselocale(), a library could assume that all
threads get consistent locale information if they ask at the same time.
Given that setlocale() can't normally be used in any sane way in a
multi-thread program, the "at the same time" is not really a
restriction. Now take a library that implements a parallel sort for
strings and is collation aware. The library provides the natural
optimization of not using threads on single CPU systems. Does
uselocale() affect the behavior of this library or not? Does it matter
if the library uses a static thread pool or not? This is a very common
pattern and one of the big reasons why C++ doesn't have thread-local
locales in the standard, but explicit locale objects.

The other point is that the far majority of use cases of uselocale()
I have seen so use it for switching to the "C" locale for some parsing
and back afterwards. It is sometimes hidden by a few layers of
indirection, but that's it. The rest is using it as fallback
implementation for lack of explicit locale functions, i.e. in STL.

> > and it is highly undesirable from a performance spective.
> 
> Why? If the locale is a single __thread variable (or a set of 6 __thread
> variables, if you prefer), it is just as fast as any __thread variable access.

Yes and __thread is slow on many platforms compared to a normal function
call or access to a global variable. Even on platforms where TLS access
is moderately fast, it can easily make common interfaces quite a bit
slower.

> > It is also by itself useless as building block as
> > pretty much any higher level runtime like C++ STL wants to have explicit
> > control over locales.
> 
> Before these functions were standardized, I would have agreed with you:
> that a decent object-oriented API for locale_t objects was the way to go,
> rather than these odd-to-use newlocale/duplocale APIs with non-extensible
> locale_t objects. But now the standard exists, and you do people a favour
> if you implement it.

I disagree. A lot. As I said above, real world code use supports my
position.

> > >   - duplocale(LC_GLOBAL_LOCALE) is broken.
> > 
> > I think this is a completely unrelated bug where thousand groupers were
> > handled incorrectly. Test certainly works on current.
> 
> I don't think it's the same as a thousand groupers bug:
>   - The number the test exercises comes out as "3.5" where "3,5" is expected.
>   - The month name comes out incorrectly as well.
>   - In the debugger, when I looked at the memory representation of
>     duplocale(LC_GLOBAL_LOCALE), I saw a pointer to some C locale data
>     followed by many NULL pointers.
> 
> But I'm pleased to hear that it will be fixed in NetBSD 8.

Hm. Could also be the protected issue. I had forgotten about that one.

Joerg