[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150527035345.GJ17573@brightrain.aerifal.cx>
Date: Tue, 26 May 2015 23:53:45 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Locale change ideas
On Tue, May 26, 2015 at 11:12:08PM -0400, Rich Felker wrote:
> 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.
Trying to work out how to do this, I ran into some interesting
things...
The naive way to do the above is just to check for the C locale name
(and its aliases) and return the static object in that case. But that
misses a lot of chances for optimization when the C locale is only
selected implicitly because "" is used and env vars are not set. The
big time this is likely is if someone does something like:
new = newlocale(LC_CTYPE_MASK, "C", (locale_t)0);
In principle, this need not be the (static) C locale since categories
other than LC_CTYPE will be initialized with the default locale.
However, in the common case where locale vars are not set, this would
yield an all-C locale.
An alternate approach is to first create the new locale_t object on
the stack, then check if it's equal to the static C locale, and only
allocate storage and copy it if it's not equal. This is what I'll
probably do, but I noticed issues that should be resolved first.
My first thought was that first creating a temp locale, then copying,
would have twice the atomic overhead, since __setlocalecat performs an
atomic operation for each category. Fortunately, it turns out that's
entirely unnecessary.
Conceptually, locale objects are immutable for their lifetimes. Even
though newlocale can modify an existing locale object, what it's
formally doing is ending the lifetime of the old one and creating a
new one. Thus there is no legal way to modify a non-global locale
object while other threads may be using it. So we can do away with the
atomics for non-global locales.
We can also get rid of atomics for the global locale simply by having
setlocale use a lock while modifying it. Since the categories might be
read concurrently without holding a lock, though, they need to be
volatile. But rather than keeping them volatile like they are now:
struct __locale_map *volatile cat[4];
let's just make the whole global_locale object volatile:
volatile struct __locale_struct global_locale;
Since __pthread_self()->locale might point to global_locale, it needs
to be a pointer-to-volatile now, but it's still nice to make
__locale_struct itself free of volatile members so we can memcpy it.
I still think we need to consider the 'consume' semantics for threads
accessing global_locale->cat[n]->... without synchronization, but
that's orthogonal to the above changes which I should be able to get
started on.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
