tzset did not catch changes tolocaltime  [BZ #21060 ]

Message ID 201812181512254503522@zte.com.cn
State New, archived
Headers

Commit Message

ma.jiang@zte.com.cn Dec. 18, 2018, 7:12 a.m. UTC
  I agree that we should  make more effort to avoid the costly file system operations(as the test shows a 10x slowdown).  
It's certainly not wise to pay a 10x slowdown to detect  changes that probably never happen.  
But it seems very difficult to keep tzset things run fast and correctly... 
A simple solution might be to add a new interface that does not reload tzdata.

By the way, there is another small problem. When TZ is not set, tzset will get into 
__tzfile_read everytime, and become very slow. If we do not care tzdata changes, 
and want a fast tzset, we could do a simple swap as following.









------------------原始邮件------------------
发件人:CarlosO'Donell <carlos@redhat.com>
收件人:Paul Eggert <eggert@cs.ucla.edu>;马江10100629;schwab@suse.de <schwab@suse.de>;
抄送人:libc-alpha@sourceware.org <libc-alpha@sourceware.org>;
日 期 :2018年12月18日 12:24
主 题 :Re: [PATCH]   tzset did not catch changes tolocaltime  [BZ #21060 ]
On 12/17/18 5:23 PM, Paul Eggert wrote:
> I followed up in the bug report, here:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21060#c1
>

In the case of reloading if TZ or /etc/localtime has changed we are in
the same realm of problem as /etc/resolv.conf reloading, it's something
we would like to be able to do, but you're going to need more cleverness
to avoid the costly operations, otherwise it's lost performance for
little to no gain. Most developers don't change /etc/localtime, and in
many countries it is a stable set of daylight savings transitions (and
if they change you need to restart).

The naive implementation is not going to be sufficient.

--
Cheers,
Carlos.
  

Comments

Paul Eggert Dec. 18, 2018, 10:06 p.m. UTC | #1
On 12/17/18 11:12 PM, ma.jiang@zte.com.cn wrote:
> By the way, there is another small problem. When TZ is not set, tzset will get into
> __tzfile_read everytime, and become very slow.

I noticed the same thing, along with a related problem where TZ=":" is 
treated differently from TZ="". I filed a bug report (along with a 
proposed patch) here:

https://sourceware.org/bugzilla/show_bug.cgi?id=24004
  

Patch

diff --git a/time/tzset.c b/time/tzset.c
index b517867..94ae747 100644
--- a/time/tzset.c
+++ b/time/tzset.c
@@ -386,15 +386,15 @@  tzset_internal (int always)
   if (tz && *tz == ':')
     ++tz;

+  if (tz == NULL)
+    /* No user specification; use the site-wide default.  */
+    tz = TZDEFAULT;
+
   /* Check whether the value changed since the last run.  */
   if (old_tz != NULL && tz != NULL && strcmp (tz, old_tz) == 0)
     /* No change, simply return.  */
     return;

-  if (tz == NULL)
-    /* No user specification; use the site-wide default.  */
-    tz = TZDEFAULT;
-
   tz_rules[0].name = NULL;
   tz_rules[1].name = NULL;