thread safety in boost date time
Boost date_time apparently has a thread safety problem in linux in that it calls localtime() in boost/date_time/time_clock.hpp and related functions rather than localtime_r() and related functions. This is even though BOOST_HAS_PTHREADS is defined by configure in user.hpp. Yitzhak Sapir
On Tue, 8 Mar 2005 11:34:15 +0200, Yitzhak Sapir wrote
Boost date_time apparently has a thread safety problem in linux in that it calls localtime() in boost/date_time/time_clock.hpp and related functions rather than localtime_r() and related functions. This is even though BOOST_HAS_PTHREADS is defined by configure in user.hpp.
That's true -- date_time doesn't do anything to ensure thread safety. I'm a little reluctant to protect these functions since the user can determine better if they need to take the associated performance hit. Of course this needs to be documented, which it isn't now. Thoughts? Jeff
Jeff Garland wrote:
On Tue, 8 Mar 2005 11:34:15 +0200, Yitzhak Sapir wrote
Boost date_time apparently has a thread safety problem in linux in that it calls localtime() in boost/date_time/time_clock.hpp and related functions rather than localtime_r() and related functions. This is even though BOOST_HAS_PTHREADS is defined by configure in user.hpp.
That's true -- date_time doesn't do anything to ensure thread safety. I'm a little reluctant to protect these functions since the user can determine better if they need to take the associated performance hit. Of course this needs to be documented, which it isn't now. Thoughts?
There is no performance hit associated with the _r functions, and the user is not necessarily in a position to insert locks around localtime calls, because he might be using date_time indirectly. In my opinion, every library must provide the basic thread-safety guarantee in its default configuration.
On Tue, 8 Mar 2005 14:48:00 +0200, Peter Dimov wrote
That's true -- date_time doesn't do anything to ensure thread safety. I'm a little reluctant to protect these functions since the user can determine better if they need to take the associated performance hit. Of course this needs to be documented, which it isn't now. Thoughts?
There is no performance hit associated with the _r functions, and the user is not necessarily in a position to insert locks around localtime calls, because he might be using date_time indirectly. In my opinion, every library must provide the basic thread-safety guarantee in its default configuration.
Well I don't think just calling the _r function is enough to ensure the thread safety of this code. I believe I would have to insert a lock in the date-time code to make this assurance. Jeff
participants (3)
-
Jeff Garland -
Peter Dimov -
Yitzhak Sapir