On Sat, Dec 31, 2016 at 1:13 AM, Zefram <zef...@fysh.org> wrote: > Warner Losh wrote: >>Other systems don't have this quite yet, but I'd love to see it more >>widely implemented. Is there a spec for this yet, > > https://www.cl.cam.ac.uk/~mgk25/posix-clocks.html
Cool, but last updated 1998... >>To do this, one would need to tell the kernel that a new leap second >>is introduced. That's not too bad, but you'd also need to then run >>through all the timers in the system to adjust the time that the UTC >>timer was going to fire to be a new time > > You're prejudging the implementation too much. The kernel does need > to know about each leap second by the time it happens, but it does not > need to convert timer expirations between TAI and UTC immediately when > the timer is set. Nor does avoiding this imply performing conversion in > the hot path on timeout. It suffices that timer settings get converted > to the operational time scale *sometime* between when they are set and > when they expire. If a timer is set to expire a year hence, it would > not be difficult to postpone the conversion until a few minutes before > it expires, by which time one can expect to be able to perform the > conversion correctly. True. I'd assumed that the kernel has one callout wheel, that wheel is in a uniform time scale, and that any conversion would need to be done at insertion time. The issue with your suggested approach is how do you know when to convert? Do you have a second callout wheel for things '> minutes' in the future that gets scanned periodically for adjustments? How does that complicate the locking and/or code paths for timer cancellation, etc. Too much time being paranoid about making change to that code in one specific system I guess. >>But I'm curious how you'd represent a leap second in this scheme? > > CLOCK_UTC is defined to use 1e9 <= tv_nsec < 2e9 in struct timespec, > by implication with tv_sec the same as it is for the preceding second. Kinky. Won't work with timegm(), et al, since they don't time a timespec to do their thing. But it certainly suggests some kind of extensions that might be worth looking into. That suffers from the conversion problem and the raw-math detection issue still, but it isn't completely horrible. Is there ongoing work in this area? I suspect that there'd be about a dozen APIs that might need to grow awareness of timespecs. >> It's especially troublesome if the kernel decides that there >>really isn't going to be a leap second at midnight for some reason > > That would require a decision on what it means to have set a timer for > a time that doesn't actually exist. It's not difficult to implement > any of the reasonable options. Yes. Generally, the sleep APIs are that you'll sleep for at least that amount of time. For the timeout api, the absolute time could be fudged a bit. Thought you'd have an information sharing problem between userland and the kernel if you wanted a timeout in UTC time potentially (how do you know that kernel / userland agree on the future evolution of UTC). >> It might be easiest if there's a flag on the UTC timeouts >>that could be adjusted across such events > > Handily, clock_nanosleep() already has a flags parameter that could be > used for that purpose. Yea, I was thinking an internal to the kernel's timeout implementation. If the kernel knows about UTC, then it can do the conversions, and also trigger on changes to its knowledge of UTC, which presumably happen infrequently enough to allow the work done in that case to be somewhat expensive and intrusive to the operation of the system for the duration of time it takes to do the work. Warner _______________________________________________ LEAPSECS mailing list LEAPSECS@leapsecond.com https://pairlist6.pair.net/mailman/listinfo/leapsecs