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

Reply via email to