RE: [boost] thread safety in boost date time

From: Jeff Garland (jeff_at_[hidden])
Date: 2005-03-08 21:11:39

On Tue, 8 Mar 2005 20:18:53 +0200, Yitzhak Sapir wrote

> Ok, having investigated the problem a little more, I get the 
> following..  The problem comes down to the fact that 
> localtime/gmtime call tzset(), which in turn calls getenv("TZ"). 
>  This call isn't done in the _r versions which use pretty much the 
> same code.  getenv() appears to be not thread safe, but I'm not sure 
> why.  This does indicate, however, that probably the _r versions are 
> a little quicker (because they don't call getenv()).  Running 
> localtime (no _r) in loops in four threads on a multi cpu machine 
> resulted in no segmentation fault.  Maybe something else is 
> interfering with getenv() in unforseeable ways?

Don't know. Maybe your just getting lucky. Anyway, I've put it on the todo
list to look at using the _r versions.   Looks like it should be a no-brainer
to do, so I expect this will be in 1.33.  Still, this is not guarantee that
all of date-time is threadsafe...
 
>...snip other stuff..
>
> A link to an example posting about a problem that seems very similar:
> 
> http://lists.gnu.org/archive/html/bug-glibc/2002-11/msg00092.html
> 
> If it is to be documented and not fixed, it should probably be
> documented in a central place for all boost.  (This is a good idea
> regardless).  I think it should be fixed, given that the main difference
> is using a static buffer vs a stack allocated buffer and that the 
> current version does more work (damage?) than the reentrant version.

Well I don't think it should be in a central place.  A quick check indicates
that date_time is the only place localtime is called (excluding a test program
in filesystem).  So seems to me we should isolate the change in date_time
until there is a motivation to push it up into the full boost config.

Jeff