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: Wed, 07 May 2014 22:31:15 -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>
Carlos O'Donell wrote:
it stands to reason you get either
the new locale or the old locale but don't know which.
It's good to know that glibc enforces this, but it's not clear that
POSIX requires it. As far as I can see, if one thread calls localtime_r
at the same time some other thread is calling tzset, the first thread
may get the old time zone, or the new one, or some indeterminate
"in-between" time zone; all that POSIX requires is that localtime_r not
Also, it seems pretty clear that glibc's enforcement of atomicity slows
down localtime_r: if two threads can't simultaneously run localtime_r,
one can easily construct scenarios where localtime_r is unnecessarily a
bottleneck. It's plausible that some users would prefer a faster,
non-bottleneck-prone localtime_r to an atomic localtime_r, if only
because they know their applications will never really need the atomicity.
P.S. Have you read the "You don't know jack" paper on shared variables?
Some pretty scary stuff there; after reading it I couldn't help having
some doubts about whether glibc correctly enforces localtime_r atomicity.
Boehm H-J, Adve SV. You don't know jack about shared variables or memory
models. ACM Queue 2011 Dec;9(12):40. doi:10.1145/2076796.2088916.