Boost logo

Boost :

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
> 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
> Butenhoff's book.
> But at least one vendor (HP-UX) chose not to provide thread-safe
> 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
> * 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
> IMO, as it will certainly result in porting bugs only detected
> when programs fail.)
> * Provide a default implementation of the above set of xxx_r
> following the POSIX spec, and warn users to avoid the Standard
> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at