On 2023-12-24 20:58, Jonathan Stone wrote:
On Sunday, December 24, 2023 at 02:43:55 AM PST, Johnny Billquist
<b...@softjar.se> wrote:
> Oh? So we are actually not POSIX compliant on that one? Interesting.
> (POSIX explicitly says that the timeout should be for an absolute time,
> which means that if you for example update the clock, moving it
> backwards, the timeout should still only happen when that time arrives,
> and not after some precomputed number of ticks.)
one could keep track, for every timeout, whether it's relative or absolute;
and when the time is changed, walk the list of a-yet-unfired timeouts,
updating all the "absolute" timeouts by the clock-change delta.
One could, indeed. And then it would be compliant. (I'd dislike it, but
that's a very personal opinion. :-) )
Anyway .. I wonder if the "clock drift" is related to the clock drift
I've heard about,
on machines which don't have a hardware cycle-counter-style clock, and
rely on clock-tick
interrupts to track time. (for example, pmax 2100/3100; decstation
5000/200; (most) vax).
I'd really like to help out with clock-drift', if I can do anything to
help.
I am fairly sure all systems use the clock tick interrupt to track time
in the end. No NetBSD port, as far as I know, is running a tickless
implementation.
But I think the suggestion that the time adjustment might actually be a
source of the problem is interesting, and should be investigated. It
just takes so bloody long to do a full build these days. I still haven't
finished, and can't start chasing this quite yet.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
