>-----Original Message----- >From: Martin Sebor [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 03, 2008 8:55 AM >To: [email protected] >Subject: Re: svn commit: r644364 - in /stdcxx/trunk: >src/locale_global.cpp tests/localization/22.locale.statics.mt.cpp > >[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> >> >> 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. 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. Travis
