This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: zonefile changes and long running processes.


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]