On 10/07/2018 06:32 PM, Victor Zverovich wrote:
> Existing programs depend on the ability to dynamically change the execution encoding (within reason) in order for a server process to concurrently serve multiple clients with different locale settings.

This seems like a very weird use case because it effectively limits server to processing requests on one thread, since as mentioned elsewhere in the document per-thread locale setting is still in the proposal phase. Do you have any examples? In my experience changing locale dynamically more often than not breaks programs' expectations.

I don't have specific examples to share.  Code that does this pretty much has to rely on extensions like POSIX uselocale() and Microsoft's _configthreadlocale() since, as you note, taking a lock to ensure global locale settings stay consistent effectively single threads requests.  A quick code search of github for these functions has lots of hits, but many are duplicate hits (if there is a way to get github to better suppress similar hits, I'd be curious to know how to do that).

I agree that dynamically changing locale is rarely a good thing to do.  It can be ok as part of program startup, but afterwards is asking for trouble - same as changing other global state like current working directory.  I just mentioned it because, despite likely being a bad idea, there is existing code that does it.


On Tue, Oct 2, 2018 at 10:21 PM Tom Honermann <tom@honermann.net> wrote:
Enclosed is a draft of an SG16 direction paper to be discussed at our
meeting tomorrow.  It's rough, but I think in sufficient shape for

If we manage to get through that paper, we'll discuss the paper Steve
just posted to our mailing list [1] and/or Markus' feedback paper [2].


[1]: http://www.open-std.org/pipermail/unicode/2018-October/000144.html

SG16 Unicode mailing list