This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]