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: Rich Felker <dalias at aerifal dot cx>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: Rich Felker <dalias at aerifal dot cx>, Alexandre Oliva <aoliva at redhat dot com>, libc-alpha at sourceware dot org
- Date: Tue, 2 Apr 2013 09:43:25 -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>
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.
Rich