[PATCH] Fix multiple minor tzset glitches [BZ #24004]

[Carlos O'Donell]

On 4/11/19 1:51 PM, Paul Eggert wrote:
> 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.

"without huge performance penalty" ;-)

Without threads you have to stat at some point to notice the file
updated. Cost.

You have to use RCU and a pointer to the binary data. Cost.

I also think we need to do something similar for locale data, and
the NSS reloading that DJ is looking at. In total that's 4 interfaces
which could use a dynamic update/commit style mechanism in glibc.
I'm going to go look and see if anyone has best practice for this in C.

The alternative:

(a) Check for update?

   Provide a function that tells the user if the on-disk data has changed.
   e.g tzdb_changed(), locale_changed(). The function lets the user control
   the cost of the stat and when it happens, but isolates them from the
   implemetnation.

(b) Commit update.

   Provide a function to do the thread-safe update, which the user can
   execute whenever they want e.g. tzset(), locale_reload(). The function
   lets the user control the cost of the reload and when it happens, and
   again isolates them from the implementation.

You still need to have something like RCU or an atomic protocol to make
the update thread-safe. That cost never goes away, but it's minor compared
to when to check and when to commit the update.
  
> 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.
  
If users have to make code changes it's better to just add a new api
for "Check for update?" and "Do the update!".

-- 
Cheers,
Carlos.