incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: svn commit: r644364 - in /stdcxx/trunk: src/locale_global.cpp tests/localization/22.locale.statics.mt.cpp
Date Thu, 03 Apr 2008 17:06:23 GMT
Travis Vitek wrote:
>  
> 
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com] 
>> Sent: Thursday, April 03, 2008 8:55 AM
>> To: dev@stdcxx.apache.org
>> Subject: Re: svn commit: r644364 - in /stdcxx/trunk: 
>> src/locale_global.cpp tests/localization/22.locale.statics.mt.cpp
>>
>> elemings@apache.org wrote:
>>> Author: elemings
>>> Date: Thu Apr  3 08:32:56 2008
>>> New Revision: 644364
>>>
>>> URL: http://svn.apache.org/viewvc?rev=644364&view=rev
>>> Log:
>>> 2008-04-03  Eric Lemings  <eric.lemings@roguewave.com>
>>>
>>> 	STDCXX-811
>>> 	* src/locale_global.cpp (std::locale::global): Replace call to
>>> 	non-reentrant setlocale() C function with reentrant
>>> 	__rw_setlocale object.
>> I don't think that's correct. The object's dtor restores
>> the original locale. We need a mutex around the call to
>> setlocale. Look for/at the _RWSTD_STATIC_GUARD() and
>> _RWSTD_CLASS_GUARD() macros.
>>
> 
> Right. It seems that for this to be mt-safe with respect to other
> library code that calls setlocale(), we would need to lock the same lock
> that is used by _RW::__rw_setlocale. If don't use the same lock it would
> be possible for the std::locale::global() call to change the locale
> while some other library code is reading locale specific data under
> protection of an active _RW::__rw_setlocale instance.

Good point. That probably means extending the __rw_setlocale
interface to release the lock without restoring the original
locale name.

> 
> Of course the _RW::__rw_setlocale objects will always be able to call
> setlocale() and mess up the state of anything expecting locale specific
> behavior to work correctly. i.e. std::locale::global() is required to
> call setlocale(), but the library may need to call setlocale()
> internally [through a _RW::__rw_setlocale instance]. When this happens,
> the global locale state [the C/C++ locale set by the setlocale()
> function] will be temporarily overridden behind the users back, possibly
> resulting in some interesting behavior.

Right. There's no avoiding it. The best we can do (and what
the test tries to exercise) is that locale::global() doesn't
crash when called simultaneously from multiple threads.

Martin

Mime
View raw message