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