Re: CVS commit: src

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Sun, 22 Mar 2026 21:56:04 +0900
> From: Takashi YAMAMOTO <yamt9999%gmail.com@localhost>
> 
> On Sun, Mar 22, 2026 at 5:45 AM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
> >
> > > Date: Fri, 20 Mar 2026 13:18:20 +0900
> > > From: Takashi YAMAMOTO <yamt9999%gmail.com@localhost>
> > >
> > > On Wed, Mar 18, 2026 at 9:18 PM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
> > > >
> > > > (See PR kern/58925: `itimer(9) responds erratically to clock wound
> > > > back' <https://gnats.NetBSD.org/58925> for what prompted the current
> > > > logic.)
> > >
> > > IMO, the correct answer for the question in the PR is (e).
> > > it doesn't make sense to fire "an interval timer to fire every minute
> > > starting at 03:00:00 on the real-time clock" at 02:01:00.
> >
> > OK, I guess, we need to distinguish relative periodic timers and
> > absolute periodic timers (TIMER_ABSTIME).
> > [...]
> > https://pubs.opengroup.org/onlinepubs/9799919799.2024edition/functions/clock_settime.html
> > [...]
> > Perhaps handling this properly requires an ito_realtime_changed
> > callback to correct the current deadlines of the relative timers to
> > DTRT; in that case, your change may be fine.
> 
> are you suggesting to change the behavior on TIMER_ABSTIME?
> i feel it's dangerous to read too much from the standard text.

I am suggesting that the standard is pretty clear on what approximate
durations are supposed to elapse between firings, and what the clock
is supposed to read (approximately) at the time of each firing, in the
absolute and relative cases.

POSIX does not, of course, bind the internal subroutine
itimer_transition I added in order to test the arithmetic, but we
should put as much relevant logic as we can into this purely
computational subroutine to facilitate automatic testing.

I am not suggesting that I have definitely worked out the right
algorithm -- I haven't had any time to think in detail about this
subject in a while.  Perhaps CLOCK_REALTIME relative timers should
just be mapped to CLOCK_MONOTONIC relative timers so going backwards
is never relevant, and CLOCK_REALTIME absolute timers should have the
behaviour you implemented.

But whatever we do should clearly spell out why it is done that way,
and make sure the test cases clearly match that reasoning.

> do you know any systems which implement posix timers that way?

I have not reviewed other implementations but I would be surprised if
POSIX spelled out this level of detail not matched by implementations.

> > > i suppose that it's somehow expected for realtime timers to behave a
> > > bit strange on a large time adjustment.
> > > although there might be a way to make it nicer, your trick doesn't
> > > seem so nice as it doesn't work well for the cases i mentioned in the
> > > commit message.
> >
> > But the case you're responding to, where the timer fires _more_ than
> 
> sorry, which case?

      /*
       * Fired more than one interval early -- treat clock as wound
       * backwards, not counting overruns.  Advance to the next
       * integral multiple of it_interval starting from it_value.
       */
      [0] = {{.it_value = {3,0}, .it_interval = {1,0}},
-            {0,1}, {1,0}, 0,
+            {0,1}, {4,0}, 0,
             NULL},

Note that now={0,1} is before it_value - 2*it_interval.

In contrast, the cases you mentioned in your commit message were, I
think, almost all about cases when

	it_value - it_interval < now < it_value,

like it_value=3sec, it_interval=1sec, and now=2.8sec.

> > one interval early, does not appear in the cases you quoted in the
> > commit message, does it?  Isn't that the following case below?
> 
> well, itimer_transition doesn't have much context.
> it_value can be the first callout, not for the interval.
> in that case, "more than one interval early" doesn't have much meaning.

I don't understand.  The semantics of a timer is that it is scheduled
to run at

	t0 + it_value
	t0 + it_value + it_interval
	t0 + it_value + 2*it_interval
	t0 + it_value + 3*it_interval
	...

where t0 = 0 for absolute timers and t0 = clock_gettime(clkid) at the
time of timer_settime/setitimer for relative timers -- assuming no
clock_settime calls.  And we always convert this to absolute it_value
internally.

So, for this test case, we have:

	it_value = t0 + 3sec
	it_interval = 1sec

And when it fires, the clock reads t0 + 0.000000001sec.  That's
2.999999999sec before it was scheduled to fire, according to the
clock, which is early by >2*it_interval, hence `more than one interval
early'.