Boost logo

Boost :

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:


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:


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

* 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.



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