This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 May 2014 08:31:59 -0700
- 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> <537628C3 dot 5060901 at redhat dot com>
Carlos O'Donell wrote:
The lockless algorithm probably gives much better performance for
localtime_r, and avoids taking a mutex and serializing against tzset.
Yes, lockless is typically faster than a mutex, but even lockless
synchronization typically has some overhead, and localtime_r needn't
suffer any synchronization overhead: it can go ahead and inspect the
tables as if it were single-threaded.
>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?
No, I mean that if one thread calls localtime_r while another thread is
calling tzset, localtime_r might not see either the old or the new
zoneinfo table; it might see some "in-between" table and produce a
timestamp that doesn't correspond to either the old or the new zoneinfo
table. As I understand it, POSIX allows such an implementation, so long
as localtime_r doesn't crash or infinite-loop.