Re: zonefile changes and long running processes.

[Paul Eggert <eggert at cs dot ucla dot edu>]

Carlos O'Donell wrote:
> The lockless algorithm probably gives much better performance for
> localtime_r, and avoids taking a mutex and serializing against tzset.

Yes, lockless is typically faster than a mutex, but even lockless 
synchronization typically has some overhead, and localtime_r needn't 
suffer any synchronization overhead: it can go ahead and inspect the 
tables as if it were single-threaded.

> > >I suspect this may be why POSIX doesn't require localtime_r to
> > >produce reliable results when invoked "at the same time" that tzset
> > >is being invoked in another thread.
> Define reliable? You mean you can't decide which zoneinfo will be used
> because localtime_r might see the old or new one?

No, I mean that if one thread calls localtime_r while another thread is 
calling tzset, localtime_r might not see either the old or the new 
zoneinfo table; it might see some "in-between" table and produce a 
timestamp that doesn't correspond to either the old or the new zoneinfo 
table.  As I understand it, POSIX allows such an implementation, so long 
as localtime_r doesn't crash or infinite-loop.