This is the mail archive of the
mailing list for the glibc project.
Re: zonefile changes and long running processes.
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Carlos O'Donell <carlos at redhat dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 13 May 2014 23:14:52 +0200
- 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>
On Wed, May 07, 2014 at 10:31:15PM -0700, Paul Eggert wrote:
> 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.
It won't be a bottleneck when properly implemented. It is relatively
straightforward to replace locking with atomics but a patch would be
ugly. There is bug report requesting this improvement.
It would need requirement that manually setting a tzname leads to
For synchronization itself following should suffice:
typedef struct tzstruct
long int __timezone;
void tz_set_internal (tzstruct *set)
tzstruct *old = atomic_exchange_acq (&ptr, set);
tzstruct *tz_get_internal ()
return atomic_forced_read (ptr);
Ugly part is allocating and filling structure in tzset and replacing
tzname et al. references with pattern like
tzstruct *tz = tz_get_internal ();
... tz->tzname ...