On Wed, Mar 15, 2023 at 7:54 AM Nathan Bossart <nathandbossart@gmail.com> wrote:
> Here is roughly what I had in mind:
>
> NOTE: Although the delay is specified in microseconds, older Unixen and
> Windows use periodic kernel ticks to wake up, which might increase the
> delay time significantly. We've observed delay increases as large as
> 20 milliseconds on supported platforms.
Sold. And pushed.
I couldn't let that 20ms != 1s/100 problem go, despite my claim that I
would, and now I see: NetBSD does have 10ms resolution, so everyone
can relax, arithmetic still works. It's just that it always or often
adds on one extra tick, for some strange reason. So you can measure
20ms, 30ms, ... but never as low as 10ms. *Shrug*. Your description
covered that nicely.
https://marc.info/?l=netbsd-current-users&m=144832117108168&w=2
> > (The word "interrupt" is a bit overloaded, which doesn't help with
> > this discussion.)
>
> Yeah, I think it would be clearer if "interrupt" was disambiguated.
OK, I rewrote it to avoid that terminology.
On small detail, after reading Tom's 2019 proposal to do this[1]: He
mentioned SUSv2's ENOSYS error. I see that SUSv3 (POSIX.1-2001)
dropped that. Systems that don't have the "timers" option simply
shouldn't define the function, but we already require the "timers"
option for clock_gettime(). And more practically, I know that all our
target systems have it and it works.
Pushed.
[1] https://www.postgresql.org/message-id/4902.1552349020@sss.pgh.pa.us
