On 2023-12-23 23:05, Taylor R Campbell wrote:
The attached (untested) patch reverts to the old algorithm specifically for the case of rearming a periodic timer, leaving the new algorithm with +1 in place for all other uses. Now, it's unclear to me whether this is correct, because it can have the following effect. Suppose ticks happen on intervals of time T. Then, owing to unpredictable and uncontrollable scheduling delays, the following sequence of events may happen: Time 0*T: timer_settime(.it_value = T, .it_interval = T), arms timer at 1*T Time 1*T + 0.9*T: timer expires, rearms timer at 2*T Time 2*T + 0.1*T: timer expires, rearms timer at 3*T The duration between these consecutive expirations of the timer is 0.2*T, even though we asked for an interval of T. Of course, the _average_ duration will be around T, but the _minimum_ duration is essentially zero. POSIX clearly forbids a _one-shot_ timer, which is scheduled to expire after time T, to actually expire after only time 0.2*T. But the language in POSIX is unclear to me on whether this is allowed for _periodic_ timers:
I would argue that the first timeout should not happen with less than T time, so the rounding up of that one is correct. The rearming should be with T. The fact that the user level program might the events with a 0.2*T interval (could even be infinitely close to 0 actually) is an effect of how systems work. You can always have higher priority stuff going on, which delays the scheduling of a process for an unknown amount. Even in soft realtime systems, that is the case. Hard realtime is pretty tricky actually, and a lot of the time, people trying to do realtime don't understand the problems around this. Anyway, this, in the end, goes to the point of what the purpose/usecase/reason for the itimer is.
I would like/prefer that they try to give that average interval. Because if not, then it have no difference to the process just doing the call in the timer signal handler itself, and the interval parameter becomes just a convenience to not have to do the call youself, and there is no way to get something that essentially gives a higher chance of getting the average rate to what you ask for. Which seems poorer than having the ability to have both the average, and a way of having a minimum interval.
But when it comes to times and timeouts, POSIX have some serious flaws already, and POSIX is close to unusable for anything realtime related anyway. (Try to do a pthread_cond_timedwait() for a specific number of seconds, and consider a time change in between and you'll see the problem.)
So it's questionable if POSIX is useful/helpful here anyway. But maybe (as Mouse suggested) we should add/have a second interface which actually provides what is useful, if POSIX insists on an always minimum interval interpretation.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol