This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Fix multiple minor tzset glitches [BZ #24004]
- From: Carlos O'Donell <codonell at redhat dot com>
- To: Florian Weimer <fweimer at redhat dot com>, Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: libc-alpha at sourceware dot org
- Date: Wed, 10 Apr 2019 09:18:37 -0400
- Subject: Re: [PATCH] Fix multiple minor tzset glitches [BZ #24004]
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 4/10/19 7:57 AM, Florian Weimer wrote:
* Paul Eggert:
On 2/18/19 1:37 AM, Florian Weimer wrote:
I thought this polling (for reloading /etc/localtime if it has changed)
was a feature. I'm not sure if we can remove it.
No such polling is documented. On the contrary, the glibc manual says
that an unset TZ is treated as if it were set to
':/etc/localtime'. There is no polling when you set
TZ=':/etc/localtime' (or to TZ='/etc/localtime', or to any other
value). So the code and the documentation disagree, and one or the
other needs to be fixed.
Neither Solaris nor OpenBSD poll, so portable programs cannot assume
that polling occurs. (These are the only two other systems I checked.)
It turns out that polling was implemented in response to this user bug
I must say that the use case in the bug report is not unreasonable.
I agree that today we have *millions* of people travelling through timezones
and they may be adjusting localtime on their laptop continuously and the
timezone should be updated and reflected in the logs.
I think this continues to show the following trend in expectation:
* APIs are MT-safe.
* APIs dynamically respond to changing context.
Few if any developers are asking us to make APIs data read-once
and immutable after reading.
Timezone information is updated on average a dozen times a year,
that's a once-a-month restart that's required to get this data
if we don't internally reload that data.
I think there *have* to be ways in which this data can be dynamically
updated without a huge performance penalty.
I find the following arguments weak:
(1) Solaris nor OpenBSD Poll.
(2) Portable programs will have to poll.
The reason I find them weak is because they do not restrict us from
doing the best we can for our developers on GNU/Linux.
We can offer polling by default, and users who only care about GNU/Linux
can write less code, and save on the maintenance of doing polling
correctly (or having to pay the full cost of tzset()).