Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/lib/libc



> On Wed, Aug 21, 2013 at 12:43:58AM +0000, YAMAMOTO Takashi wrote:
>> > On Tue, Aug 20, 2013 at 03:31:01PM +0000, YAMAMOTO Takashi wrote:
>> >> > On Tue, Aug 20, 2013 at 09:31:18AM +0000, YAMAMOTO Takashi wrote:
>> >> >> > Module Name: src
>> >> >> > Committed By:        joerg
>> >> >> > Date:                Mon Aug 19 22:43:28 UTC 2013
>> >> >> > 
>> >> >> > Modified Files:
>> >> >> >      src/lib/libc/citrus: citrus_lc_ctype.c
>> >> >> >      src/lib/libc/gen: isctype.c
>> >> >> >      src/lib/libc/locale: global_locale.c setlocale_local.h
>> >> >> > 
>> >> >> > Log Message:
>> >> >> > Remove most LC_CTYPE specific parts of locale.cache.
>> >> >> 
>> >> >> why?
>> >> > 
>> >> > Unlike the locale parts, the cache is currently not invariant and also
>> >> > not updated atomically. I am working on fixing that. It is useful for
>> >> > run time memory usage to remove redundant fields and reduce the number
>> >> > of categories that affect the cache.
>> >> 
>> >> for what purpose do you need atomic update?
>> > 
>> > In a multi-threaded application, calling nl_langinfo or localeconv
>> > should provide consistent results. It doesn't do that ATM.
>> 
>> - who updates them behind nl_langinfo/localeconv?
> 
> setlocale

i don't think it's supposed to work.
is there any standard which mandates it,
or any application which assumes it?

> 
>> - does looking at part_impl directly make them atomic?  how?
> 
> part_impl doesn't change after creation, so changes are visible at the
> point that part_impl is updated. This is the best that can be done
> without using explicit locking. It ensures that at least all data
> from the same category is consistent.

thanks for explanation.
is there anything which needs such a consistency?

YAMAMOTO Takashi

> 
> Joerg


Home | Main Index | Thread Index | Old Index