This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: zonefile changes and long running processes.

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 crash.

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]