zonefile changes and long running processes.

[Ondřej Bílka]

On Tue, May 13, 2014 at 06:22:34PM -0700, Paul Eggert wrote:
> Ondřej Bílka wrote:
> >On Tue, May 13, 2014 at 02:41:31PM -0700, Paul Eggert wrote:
> >>does POSIX allow localtime_r to have
> >>undefined behavior if some other thread is simultaneously invoking
> >>tzset?
> >
> >yes, it would as is now.
> 
> If POSIX says that, then what does it mean for tzset and localtime_r
> to be thread-safe?  If localtime_r can crash the system whenever
> another thread is calling tzset, how can that be considered
> "thread-safe"?
> 
> >A simplest solution would be replace mutex there with rwlock so
> >localtime do not block each other.
> >
> >A faster solution would be add counter for localtime_r, a tzset would
> >free previous buffers when a counter is zero, otherwise it would just
> >add a buffer to list of buffers that should be freed.
> 
> All of these slow down localtime_r, if only somewhat.  Can't
> localtime_r run full-speed, without worrying about getting a lock or
> adding to a counter or whatnot?  After all, localtime_r is not
> required to be atomic; it's required only to be thread-safe.

Could but it would not make a big difference, a localtime call takes 2000 cycles, 
a rwlock/counter would definitely fit to 500 cycles in worst case when
there is no tzset and hardware supports atomics.

As we do not free a timezone string we could do same, construct
immutable structure with precomputed data that and look if there is
already such structure. It would take only one read for localtime_r
which is fast enough.