contrib/netbsd-tests/lib/libc/sys/t_getitimer.c
198 ↗	(On Diff #77073)	This invariant (the old and the new one) seems a bit curious and racy (in both the FreeBSD and NetBSD cases). The behavior in the NetBSD case seems more functionally correct, given the documentation, but again.. is racy. I don't like the new invariant since it shouldn't take longer than 1 usec to complete (the resolution of the system clock with ITIMER_REAL is 10 msec, but I can see where virtual platforms would skew). Maybe the better way to check this is whether or not the value is within a threshold with timercmp. I'll poke around and see if NetBSD fixed this a different way.

contrib/netbsd-tests/lib/libc/sys/t_getitimer.c
198 ↗	(On Diff #77073)	The behavior of FreeBSD seems more useful. It also matches Linux. POSIX (2013) marks `setitimer` obsolescent with a recommendation to use `timer_settime` instead. `timer_settime` returns "the previous amount of time before the timer would have expired." That's still not entirely clear, but it seems clear enough. These timers operate in wall-clock time. The process could get context-switched out between the two syscalls, allowing an unknown amount of time to pass. A VM on an oversubscribed host could get switched out for a long time, possibly making even the current code too restrictive. Granted, that's an extreme case. I could reduce the tolerance to some 100's of ms, but I wouldn't make it any less. (It might be nice to centralize the test suite's idea of allowed timer/scheduler slop, maybe even making it tunable at runtime, but that's out of scope here.)