Re: zonefile changes and long running processes.

[OndÅej BÃlka <neleai at seznam dot cz>]

On Fri, May 16, 2014 at 11:03:31AM -0400, Carlos O'Donell wrote:
> 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.
>
That is not big problem as we already need to leak timezone names (see
__tzstring).
 
> 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 suggested these at sibling thread. For lockless algorithm problem is
detecting when you could free data. You would need to keep a counter how
many readers are available. A rwlock is implementation is same when
there are no tzsets* so you could get same functionality by replacing
lock with rwlock.

* This assumes good rwlock implementation, which is atomically maintain
a number of readers and wake writer when it reaches 0