From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7780 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Locale change ideas Date: Tue, 26 May 2015 23:12:08 -0400 Message-ID: <20150527031208.GA5255@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1432696351 22822 80.91.229.3 (27 May 2015 03:12:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 May 2015 03:12:31 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7792-gllmg-musl=m.gmane.org@lists.openwall.com Wed May 27 05:12:29 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YxRld-00041d-5v for gllmg-musl@m.gmane.org; Wed, 27 May 2015 05:12:29 +0200 Original-Received: (qmail 25825 invoked by uid 550); 27 May 2015 03:12:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 25773 invoked from network); 27 May 2015 03:12:21 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7780 Archived-At: 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 against LC_NUMERIC radix points and such would be fail-safe and high-performance. One caveat: freelocale needs to be aware of these static locale objects so it doesn't try to free them, and newlocale also needs to call calloc rather than modifying-in-place when using them as a base. Eliminating the messages_name field from the locale struct. I don't like the way it's subject to data races. Even if changing locale out from under other threads is not meaningful, it should not have data races this bad. My thought is to intern a __locale_map object whenever a new name is selected for LC_MESSAGES, even if the name does not map to a locale file (now we intern only existant locales). When the locale file does not exist, the map would just contain an empty/NOP mo image and the requested name. Then (1) the object would not be accessed until its permanent name is in place, and (2) switching messages language names would inherit atomic semantics from the handling of all other locale categories. Handling non-synchronized reads of locale categories. The cat[] pointers are updated atomically, but there's no barrier on the reading side. This is okay and totally correct from an "I don't want atrociously bad performance to support broken code" standpoint, but I think we should take some effort to make sure it's safe. I don't mind if a thread that hsan't synchronized with the changes to the locale object doesn't see the latest settings, but I am worried about what happenes when it reads the __locale_map objects that the cat[] pointers point to. Is there a way to guarantee that if they see p, they also see any stores to *p sequenced before the update of p by a barrier? This is related to the nightmare that is consume-order, I think. Rich