Michael Hunter wrote: > On Wed, October 7th, at 10:15.2 of a second I called this function with > when = 1. I end up with an event on the queue for Wed, October 7th, at > 10:16 (10:15.2 + 1 is 10:16). Timer set for 1 second from 10:15.2 at > 10:16.2. > > On Wed, October 7th, at 10:16.1 I call with when = 1. I ended up with > a queue that looks like 10:16, 10.17. I don't reset the timer because > e->event_time - now is 0. If I don't do an expire in this timeframe > and cancel the timer in that code then I let the timer run out to > 10:16.2 coming close to the originally expected 1s. I then reset the > timer to 10:17.2. > > On Wed October 7th at 10:16.9 I call with when = 1. Now the queue > looks like 10:17, 10.18 and I reset the timer to 10:17.9 (note that the > event which I originally scheduled for 10:17.2 ends up firing .7s later > then that). > > The granularity of when might be 1s, but the granularity of reality > isn't :) > This leads to the question of how we want our daemon to behave. Do we care that things happen in the same microsecond or nanosecond that it was meant to happen? If we say the alarm should go off 1.1 second, is the .1 really important? What if the alarm is delayed by 0.3 seconds? Should we move to ualarm(3C) instead of the current alarm(2)? Whichever alarm we use,
> alarm(2) > > Processor scheduling delays may prevent the process from > handling the signal as soon as it is generated. > ualarm(3C) > > Because of scheduling delays, resumption of execution when > the signal is caught may be delayed an arbitrary amount of > time.
