RE: [boost] thread safety in boost date time

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.

Jeff