zonefile changes and long running processes.

[Ondřej Bílka]

On Wed, May 07, 2014 at 10:31:15PM -0700, Paul Eggert wrote:
> 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.
>

It won't be a bottleneck when properly implemented. It is relatively
straightforward to replace locking with atomics but a patch would be
ugly. There is bug report requesting this improvement.

It would need requirement that manually setting a tzname leads to
undefined behaviour.

For synchronization itself following should suffice:

#include <atomic.h>
typedef struct tzstruct
{ 
  char *__tzname[2];
  int __daylight;
  long int __timezone;
  int malloced;
}

tzstruct *ptr;
void tz_set_internal (tzstruct *set)
{ 
  tzstruct *old = atomic_exchange_acq (&ptr, set);
  if (old->malloced)
    free (old);
}

tzstruct *tz_get_internal ()
{ 
  return atomic_forced_read (ptr);
}

Ugly part is allocating and filling structure in tzset and replacing
tzname et al. references with pattern like

function (...)
{
  tzstruct *tz = tz_get_internal ();
  ...
  ... tz->tzname ...