From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-09-10 15:48:28
Several C++ Standard Library functions (all inherited from C) are
particular problems for implementors thread-safe versions of the Standard
Library because they hold internal state between calls:
rand
strtok
asctime
ctime
gmtime
localtime
It is actually possible to write thread-safe implementations of these by
using thread-specific storage; several C++ compiler vendor's
implementations do so - the technique is well-know and is explained in
Butenhoff's book.
But at least one vendor (HP-UX) chose not to provide thread-safe versions
of the above functions in their otherwise thread-safe runtime
library. Instead they provide reentrant versions, with additional
arguments to workaround the internal state issues:
rand_r
strtok_r
asctime_r
ctime_r
gmtime_r
localtime_r
These are based on a POSIX spec I'm guessing.
So what should we do so users of Boost.Threads can write portable code?
* Just warn users, and let them deal with having to use say asctime() in
some implementations and asctime_r() in other. (This is a poor solution,
IMO, as it will certainly result in porting bugs only detected painfully
when programs fail.)
* Provide a default implementation of the above set of xxx_r functions,
following the POSIX spec, and warn users to avoid the Standard Library
functions.
* Provide better, thread-safe, C++ oriented solutions. Haven't our Random
Number and Tokenizer libraries already done that for the first two on the
list? (I haven't looked at the code; is it thread-safe?) So what would be
left is a Boost time and date library, something that has been mentioned in
the past.
Opinions?
--Beman