zonefile changes and long running processes.

[Paul Eggert]

Carlos O'Donell wrote:
> it stands to reason you get either
> the new locale or the old locale but don't know which.

It's good to know that glibc enforces this, but it's not clear that 
POSIX requires it.  As far as I can see, if one thread calls localtime_r 
at the same time some other thread is calling tzset, the first thread 
may get the old time zone, or the new one, or some indeterminate 
"in-between" time zone; all that POSIX requires is that localtime_r not 
crash.

Also, it seems pretty clear that glibc's enforcement of atomicity slows 
down localtime_r: if two threads can't simultaneously run localtime_r, 
one can easily construct scenarios where localtime_r is unnecessarily a 
bottleneck.  It's plausible that some users would prefer a faster, 
non-bottleneck-prone localtime_r to an atomic localtime_r, if only 
because they know their applications will never really need the atomicity.

P.S. Have you read the "You don't know jack" paper on shared variables? 
  Some pretty scary stuff there; after reading it I couldn't help having 
some doubts about whether glibc correctly enforces localtime_r atomicity.

Boehm H-J, Adve SV. You don't know jack about shared variables or memory 
models. ACM Queue 2011 Dec;9(12):40. doi:10.1145/2076796.2088916.
http://queue.acm.org/detail.cfm?id=2088916