This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]