This is the mail archive of the libc-help@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: [RFC]setlocale() race condition


> On Wed, Jun 11, 2008 at 11:45 PM, Sharyathi Nagesh 
> <sharyath@in.ibm.com> wrote:
> >        Since the man page of setlocale() doesn't talk any thing about 
the
> > call `not being re-entrant` I assume  setlocale() to be re-entrant
> 
> setlocale() is not on the POSIX.1 list of async-signal safe functions
> and is therefore not re-entrant or thread-safe.
> http://www.opengroup.org/onlinepubs/009695399/functions/
> xsh_chap02_04.html#tag_02_04

Actually, setlocale() is required to be thread-safe (System Interfaces
and Headers, Sec. 2.9.1) but you are right in that it need not be
async-signal-safe (System Interfaces and Headers, Sec. 2.4.3). Thus,
setlocale() should not be assumed to be re-entrant.

> Please note that re-entrancy and thread safety are related but
> different terms. A re-entrant function need not be thread safe,
> imagine two threads passing in the *same* structure to a re-entrant
> function, without synchronization access to the structure is
> unpredictable. A non-re-entrant function may be thread safe if access
> to the global state is synchronized.
> 
> Are you suggesting that setlocale() although not re-entrant, should be
> made thread safe according to the standard?

It looks like Sharyathi is pointing out a thread-safety issue, with
multiple threads hitting setlocale() at about the same time.

Mark Brown
bmark@us.ibm.com


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