On 2024-02-18 06:38, Bruno Haible wrote:
- How can the caller do the caching for something internal to the callee?
The caller calls tzalloc, gets a timezone object, and calls tzfree when
it no longer needs that timezone object.
- The NetBSD code [1][2] does locking in the top-level functions (tzset,
mktime, strftime). I guess that it is because NetBSD uses global variables
(tzname, timezone, daylight, altzone).
This is for backward compatibility, and is required for POSIX
compatibility. It has obvious problems with threads. New code should not
use these vestigial interfaces. They should use localtime_z and
mktime_z. (There should be no need for strftime_z.)
https://data.iana.org/time-zones/theory.html#vestigial
For Gnulib, I intend to avoid global variables of this kind — they belong
in data allocated for each time zone — and therefore move the locking to
lower levels. In the frequent case that a timezone is used for the second
time or later, no locking will be needed at all; this will thus be faster
than what NetBSD does.
You're right to avoid the global variables, but I don't see why tzalloc
needs to lock, even in MS-Windows. Perhaps there could be an "I'll do
the caching" layer above tzalloc, but the lower-level code need not lock
at all.
