This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Fix multiple minor tzset glitches [BZ #24004]
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
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.
(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
(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.
If users have to make code changes it's better to just add a new api
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
for "Check for update?" and "Do the update!".