This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 May 2014 11:03:31 -0400
- Subject: Re: zonefile changes and long running processes.
- Authentication-results: sourceware.org; auth=none
- References: <53632771 dot 9080903 at redhat dot com> <53632B7C dot 9040201 at cs dot ucla dot edu> <53633734 dot 5010406 at redhat dot com> <53633965 dot 3010606 at cs dot ucla dot edu> <53633D96 dot 6070306 at redhat dot com> <5363DD40 dot 2040408 at cs dot ucla dot edu> <53642A07 dot 1040107 at redhat dot com> <53648418 dot 6000301 at cs dot ucla dot edu> <536AE8E0 dot 8090907 at redhat dot com> <536B16A3 dot 1010403 at cs dot ucla dot edu> <536BA15B dot 6020102 at redhat dot com> <536BACC6 dot 50604 at cs dot ucla dot edu>
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.