file src/setlocale.cpp: 83 // acquire global per-process lock 84 __rw_setlocale_mutex._C_acquire (); 85 86 // retrieve previous locale name and check if it is already set 87 const char* const curname = ::setlocale (cat, 0);
The mutex doesn't need to be locked just to read the current locale name, does it? Brad. > -----Original Message----- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 03, 2008 11:06 AM > To: [email protected] > Subject: Re: svn commit: r644364 - in /stdcxx/trunk: > src/locale_global.cpp tests/localization/22.locale.statics.mt.cpp > > Travis Vitek wrote: > > > > > >> -----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. > > 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 >
