From: Ken Shaw (ken_at_[hidden])
Date: 2001-09-10 16:22:38
----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
Sent: Monday, September 10, 2001 3:48 PM
Subject: [boost] Standard Library problems w/multi-threading
> 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
> 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
> the past.
After attempting to implement a Date/Time class several times and never
really getting a satisfactory version I would love to see a Boost library
with an eye towards eventual submission to the standards committee. If
anyone tries this I hope they will avoid the pitfalls inherit in the old C
time functions. In particular it should be possible to represent any
reasonable date and not be limited to a scale represented by the storage of
seconds since 1/1/1970.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk