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