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