Re: zonefile changes and long running processes.

["Carlos O'Donell" <carlos at redhat dot com>]

On 05/08/2014 12:11 PM, Paul Eggert wrote:
> On 05/08/2014 08:23 AM, Carlos O'Donell wrote:
>> We could make glibc's implementation more MT-friendly by having a
>> single pointer we atomically swap to point at the new zoneinfo and
>> thus don't slow down localtime_r with locks.
> 
> With an approach like that, how would the old zoneinfo be reclaimed
> reliably?  A localtime_r could be stalled in another thread
> indefinitely, no?  So tzset could never reclaim the old zoneinfo and
> would leak memory.  Unless we also assume a thread-safe garbage
> collector -- is that a direction we want to go?

It was an off-the-cuff suggestion, that yes, would require keeping
all old zoneinfo data.

The alternative is a lockless algorithm. We could lift
the one we're using for dynamic allocation of function pointers
(ia64, hppa), and refactor for more than one use. That algorithm is
in dl-fptr.c and is a simple lockless list with the ability to handle
all the conditions you might have with multiple threads creating the
same table, or entry, and arbitrating that.

The lockless algorithm probably gives much better performance for
localtime_r, and avoids taking a mutex and serializing against tzset.

Feel free to work on it, I'd support it :-)

> 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? That's always going
to be the case though until we have a new API.

> It sounds like an application that wants to monitor zonefile changes
> and update the timezone info asynchronously would be in trouble if we
> also want localtime_r to not be a bottleneck.

Yes, localtime_r would suffer a performance degradataion until we upgraded
to a lockless algorithm.

Cheers,
Carlos.