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: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 May 2014 13:53:39 +0200
- Subject: Re: zonefile changes and long running processes.
- Authentication-results: sourceware.org; auth=none
- References: <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> <20140513211452 dot GD15468 at domone dot podge> <5372918B dot 2090407 at cs dot ucla dot edu> <20140513223354 dot GA17555 at domone dot podge> <5372C55A dot 70800 at cs dot ucla dot edu> <20140514081757 dot GA19066 at domone dot podge> <537377A9 dot 1020206 at cs dot ucla dot edu>
On Wed, May 14, 2014 at 07:03:21AM -0700, Paul Eggert wrote:
> OndÅej BÃlka wrote:
> >As we do not free a timezone string we could do same, construct
> >immutable structure with precomputed data that and look if there is
> >already such structure. It would take only one read for localtime_r
> >which is fast enough.
> That's more like it. But we can do even better: localtime_r can simply
> look at the structure and use it, without testing whether there is
> already such a structure. That would avoid an unnecessary branch.
> If the initial version of the precomputed structure (all zeros,
> say?) is valid, and if localtime_r can't dump core merely because
> the structure is being updated by some other thread's call to tzset,
> this would conform to POSIX.
It would be nice to have but patch will not write itself. My point was
that adding atomicity is not that expensive. A thread safety is
requirement but its often better to crash than return date 2.3.1972 as
date which could theoretically happen if variables would be modified