Re: CVS commit: src

[Takashi YAMAMOTO <yamt9999%gmail.com@localhost>]

On Thu, Mar 26, 2026 at 1:13 PM Taylor R Campbell <riastradh%netbsd.org@localhost> wrote:
>
> > 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.

ok.
i made a bit research myself.
linux seems to turn realtime non-absolute timer_settime into
monotonic, saying "posix magic".
maybe we can follow it.

>
> > > > 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'.

it_interval only make sense after the initial it_value, does it?