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, 16 May 2014 13:39:36 -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> <537628C3 dot 5060901 at redhat dot com> <53762F6F dot 6020008 at cs dot ucla dot edu>
On 05/16/2014 11:31 AM, Paul Eggert wrote:
> 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.
Yeah, we never want that to be the case in glibc, and we'd probably
adjust the safety notes to indicate MT-safe and that you either get
the old or new one. Thus we would guarantee more than POSIX because
the alternative is not being able to detect the latest installed
zoneinfo (becuase you can't call tzset in an MT environment that is
also running localtime_r).
Cheers,
Carlos.