> So even though we added one tick, you can still get two timer events > in much closer proximity than a single tick as far as the process is > concerned.
Certainly. I think that's unavoidable without resetting the timer inside the signal handler, or hard realtime guarantees (which are Not Easy). > And we probably do need to talk about the timer expiration and > rearming as separate from signal deliver and process scheduling. There are plenty of reasons user code running the signal handler may be delayed from the time the timer is supposed to tick. But without the timer ticking as requested, I don't think the rest matters nearly as much. When even an _unloaded_ machine can't get the ticks it asks for, something is wrong. A machine which gets that overloaded just from delivering 100 signals to a mostly-trivial signal handler per second, well, I doubt NetBSD runs on anything that weak. > And from a program point of view, that is what really matters in the > end. If the program really wants a minimum amount of time before the > next timeout, it needs to do the request for the next time event at > the processing point, not something kernel internal which happend > very disconnected from the process. Agreed. ITIMER_REAL in the form I've been arguing for is of little help to a process that wants timer ticks separated by a hard minimum interval as seen by the signal handler. At least when using it_interval to get repeated signals. But then, so is every other ITIMER_REAL I've ever used. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B