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: Wed, 07 May 2014 22:16:00 -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>
On 05/03/2014 01:52 AM, Paul Eggert wrote:
> Carlos O'Donell wrote:
>> That is not correct, tzset is MT-safe, and documented in the glibc
>> manual as such.
>
> Sorry, my use of the term "thread-safe" was incorrect. I was
> thinking of the problem of ensuring that a thread that calls
> localtime_r is insulated from another thread simultaneously calling
> tzset, i.e., that the tzset will appear to occur either all before or
> all after the localtime_r. As far as I know MT-Safe does not imply
> this sort of atomicity, so an application cannot assume it.
That's right, POSIX says nothing about the happens-before or happens-after
conditions on the "as if it called tzset" statement. Thus you can't
prove anything about the behaviour. A call to localtime_r may or may not
get the new zoneinfo applied or not, but you don't know.
However, in glibc we use a lock to serialize between localtime and
localtime_r.
One might argue that since POSIX tries to avoid data races, and correct
operation should be data race free, it stands to reason you get either
the new locale or the old locale but don't know which.
>> Having tzset be MT-safe will not slow down localtime_r
>
> Wouldn't having tzset and localtime_r exclude each other slow down
> localtime_r? And if they don't exclude each other, shouldn't
> application writers avoid the abovementioned situation if they want
> localtime_r's results to be reliable?
I see what you're getting at now. Yes, having a strict definition of
happens-before or happens-after between tzset and localtime_r will
cause localtime_r to be serialized in some way against tzset that
*may* slow it down.
However, as I wrote above both localtime and localtime_r in glibc already
take the tzset lock so either you do, or you don't get the new timezone
depending on who acquired the lock first. You get no intermediate
state. We already slowdown localtime_r against localtime calls that
may themselves call tzset. However, in the case of localtime_r you take
the lock, notice you have nothing to do and release the lock after
computing the struct tm.
> Please bear with me here, as I'm by no means an expert on the various
> aspects of thread-safety in glibc.
Paul, I have infinite patience for any and all questions asked by
those people whom I know want to learn and help make this better for
our users. No need to apologize. I'll answer the same question a million
times... hopefully with the same answer ;-)
As I stated before, the scope of this particular thread should remain
solely fixed on zonefile changes during MT operations that use the
various time API functions. I don't want to wander afield of the original
discussion.
Cheers,
Carlos.