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, 02 May 2014 22:52:24 -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>
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.
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?
Please bear with me here, as I'm by no means an expert on the various
aspects of thread-safety in glibc.