This is the mail archive of the
libc-alpha@sourceware.org
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, 02 May 2014 02:39:18 -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>
On 05/02/2014 02:21 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> What about the a polling design using tzset?
>
> I'm a bit fuzzy about what that design would be. That being said,
> won't having tzset poll be likely to fail in a high-performance
> application that uses localtime_r instead of localtime? localtime_r
> doesn't call tzset.
The design would require the process to call tzset frequently
to re-read the timezone information. This can be done from some
event thread, or just before it's used by other functions. Our
current tzset code will stat the file to see if it changed and
reload it.
While localtime says it acts as-if it called tzset, and our
internal implementation does that, you are right in that localtime_r,
per POSIX doesn't say anything about calling tzset. The glibc
implementation uses this to optimize out the reloading of the zonefile.
Thus you must explicitly call tzset frequently and before the use
of localtime_r if you want to attempt to guarantee, as close as you
possibly can, a correctly printed time.
Does that make sense?
So the zonefile changing won't get noticed until you call tzset
again and it's always the applications responsibility to do so?
Cheers,
Carlos.