This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix multiple minor tzset glitches [BZ #24004]
- From: Paul Eggert <eggert at cs dot ucla dot edu>
- To: Carlos O'Donell <codonell at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 11 Apr 2019 10:51:30 -0700
- Subject: Re: [PATCH] Fix multiple minor tzset glitches [BZ #24004]
- References: <20190211163728.31655-1-eggert@cs.ucla.edu> <87h8d1e8tk.fsf@oldenburg2.str.redhat.com> <9f3882f6-e056-95d1-4506-58fd87cbf6c2@cs.ucla.edu> <875zrmysxa.fsf@oldenburg2.str.redhat.com> <1be6d504-94b4-475d-9b36-43381a4d07f8@redhat.com>
On 4/10/19 6:18 AM, Carlos O'Donell wrote:
> I think there *have* to be ways in which this data can be dynamically
> updated without a huge performance penalty.
What ways are those, though? It's not like the penalty is zero.
One possible compromise would be for localtime to poll, and for
localtime_r to not poll (you must call tzset to poll), and tell people
"if you want performance, use localtime_r". That might hit a sweet spot
of doing polling for naive programs where performance matters, and
giving higher performance for applications that care about timestamp
performance.