From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-13 11:33:21
On Sun, 13 Mar 2005 12:43:37 +0200, Yitzhak Sapir wrote
> Regarding the thread safety issue relating to getenv() in
> boost date_time, we have now identified the problem and
> it appears to be a call to putenv() elsewhere in log4cxx.
> putenv() is usually not bad, but here there is a call to
> putenv() with a string created on the stack. When the
> thread ends, the stack gets destroyed and further calls
> to getenv() cause an access violation. So the bug was
> not thread safety, but simply an ugly bug in log4cxx.
Thanks for the update on the problem.
> However, the fact remains that the date_time library
> uses non-thread safe functions in a way that cannot be
> controlled by the user.
> ...snip details...
Yes, as I said earlier it's on the todo list for 1.33. BTW, worst case is
that we could make our own localtime_r function in the clock classes.
> When I mentioned it should be
> in a central place, this is because there are various
> libraries, such as spirit, that require (or required -- we're using
> 1.30.2) BOOST_SPIRIT_THREAD_SAFE to be defined, and so
> it would be nice if all "what you need to do to work in multi-
> threaded environments" was all in one central place, rather than
> forcing the user to collect bits of information on this issue from
> each of the various libraries.
I see. So is BOOST_HAS_THREADS or BOOST_DISABLE_THREADS the correct macro for
libraries to use? Seems like if DISABLE_THREADS is set then we could safely
call the non-reentrant versions.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk