Paul Eggert wrote:
> > Note also: The above approach will need locking, in order to protect caches
> > (in 1) the data for a single time zone, in 3) the contents of tzdata.zi).
>
> The idea I had was to go more in the NetBSD / TZDB direction. These
> implementations don't need either locks or lock-free caching algorithms,
> because it's the caller's responsibility to cache.
I don't understand what you mean:
- How can the caller do the caching for something internal to the callee?
I've never seen callbacks being used for that purpose. I've once seen
a calling convention where the caller allocates memory for a cache and
passes it to the callee; but that was for a case where the cache's
lifetime ends when the callee returns.
- 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).
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.
Bruno
[1]
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/time/localtime.c?rev=1.141&only_with_tag=MAIN
[2]
http://cvsweb.netbsd.org/bsdweb.cgi/~checkout~/src/lib/libc/time/strftime.c?rev=1.55
