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:
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk