[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 06 Dec 2013 00:36:29 +0000
From: Laurent Bercot <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCHv2] Add support for leap seconds in zoneinfo files
> The problem is that gmtime is not permitted to do so. tzset has side
> effects like making the globals timezone and daylight change, and
> certain time functions are specified to behave as if they call it,
> while others are not (and therefore can't).
I don't see anything in POSIX that forbids gmtime() to call tzset(),
but if you're referring to the case where a user calls gmtime() and
expects the "daylight" variable to remain unchanged, then yes, I agree
that it is a problem.
> The only way I see around
> this is fairly invasive: possibly keeping around two timezones. Or
> (almost equivalent) keeping timezone and leapseconds profiles
> completely separate.
I'm all for keeping timezone information (which is about conversions
between UTC and local time) separate from leap second information (which
is about conversions between system time and UTC).
The tzdata package actually provides the leap second table as a separate
file, and it was pretty bad design to include it into the zoneinfo binary
files in the end.
I have two suggestions:
1. Keep using the leap second information provided in the timezone
files, but have a __leapsecs_init() function used by tzset, gmtime and
friends, that only initializes __leapsecs_num and abbrevs_end, without
other visible side effects. It requires mapping the file, so adding a
flag to know whether tzset() has been called or not. It still makes gmtime
depend on TZ.
or 2. Compile a separate leap second information binary file along with
the libc, and have a system-wide switch telling musl to use the leap second
table or not. (And default to POSIX when the file does not exist, of
course.) This is the approach I'm using with skalibs, and it's working for
me, but the requirements for a libc may be different.
> [locking issues]
> Note that the problematic aspects that are coming up are most
> problematic because they're affecting not just users who want
> leapseconds, but all users. If leapseconds affect gmtime and
> leapseconds depend on TZ, all the sudden these issues apply to all
> calls.
This goes in favour of the "keep the leap second table in a separate
file" design. We could drop the need for locking entirely, since a
file can be atomically replaced, and new leap second announcements are
rare enough that the policy could simply be to restart long-lived
processes (to get the new mapping) when the file changes.
Strictly POSIX systems wouldn't be impacted at all anyway.
--
Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
