This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Thread-, Signal- and Cancellation-safety documentation
- From: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: Florian Weimer <fweimer at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 2 Apr 2013 15:30:47 -0400
- Subject: Re: Thread-, Signal- and Cancellation-safety documentation
- References: <orppym7okv dot fsf at livre dot home> <20130326064347 dot GL20323 at brightrain dot aerifal dot cx> <515AB073 dot 9000500 at redhat dot com> <20130402134325 dot GO20323 at brightrain dot aerifal dot cx>
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.