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