From: williamkempf_at_[hidden]
Date: 2001-09-10 22:11:28
--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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.
An alternative you missed that should go right after the above:
* Provide thread safe implementations of xxx functions by utilizing
thread specific storage. These would be in the boost:: namespace to
avoid collision with standard versions.
> * 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.
I'd opt for this one in most cases, though one of the two previous
(yours and mine) options might be needed for legacy code.
Bill Kempf