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: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 15 May 2014 07:41:16 -0700
- 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> <20140515115339 dot GA13301 at domone dot podge>
OndÅej BÃlka wrote:
its often better to crash than return date 2.3.1972
Isn't the general glibc preference to use whatever's simplest and
cheapest when the behavior isn't specified? Even if supporting
atomicity is not that expensive -- which remains to be seen -- most
likely it will cost *something*. As I understand it, a design goal of
POSIX's localtime_r spec was to not require interlocking with tzset, so
as implementers why not exploit this to improve localtime_r's performance?
patch will not write itself