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:
> It is actually possible to write thread-safe implementations of
> 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:
> 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
> 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
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
> Number and Tokenizer libraries already done that for the first two
> list? (I haven't looked at the code; is it thread-safe?) So what
> left is a Boost time and date library, something that has been
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk