zonefile changes and long running processes.

[Paul Eggert]

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?

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.

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.