Re: Thread-, Signal- and Cancellation-safety documentation

[KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>]

On Tue, Apr 2, 2013 at 9:43 AM, Rich Felker <dalias@aerifal.cx> wrote:
> On Tue, Apr 02, 2013 at 12:18:27PM +0200, Florian Weimer wrote:
>> On 03/26/2013 07:43 AM, Rich Felker wrote:
>> >>As a result, many functions were marked as unsafe, with “glocale” as the
>> >>reason.  More recently, talking to Carlos about the consequences of this
>> >>and debating how best to approach the need for some functions to be
>> >>MT-Safe in spite of setlocale, we decided to document setlocale itself
>> >>as unsafe, so that calling it after starting threads was documented as
>> >>problematic.  Then, we could document the fast-path functions as MT-Safe
>> >>even though they don't bother with locking.
>> >
>> >Per POSIX, setlocale is thread-safe.
>>
>> But is this really meaningful because of the way it changes global
>> state?  For example, setlocale followed by strcoll is still not
>> thread-safe in the sense that the strcoll call is guaranteed to use
>> the requested locale.
>
> It's meaningful in the sense that the program does not invoke
> undefined behavior by making the call; instead, it just has an
> inherent indeterminism as to whether strcoll uses the old locale or
> the new locale. But it would be non-conforming for strcoll to crash or
> to mix data from the two locales, etc.
>
> Also, the behavior is entirely well-defined if the thread calling
> strcoll has previously called uselocale to setup its own thread-local
> locale.

That's why I recommend to use "MT-safe with exceptions". I believe
both Florian and Rich are correct. and both MT-safe and MT-unsafe
are terribly confusable. In fact, POSIX "thread safe" definition is not
human friendly. We need long glocale explanation either.