On Wed, 07 Oct 2009 14:20:06 -0400
"Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
> 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,
More generally do we care that if we want the alarm to be in N seconds
that really means the alarm will trigger sometime within N-1 and N+2 (I
think that is right although given how we deal with short timers it
might really be tighter on the short side?) seconds. That is kinda
fat. But I suspect we don't care. I just want it understood and
documented.
>
> > 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.
>
Knowing this is why I originally questioned your assumptions.
Personally I'd use timer_settime() instead of ualarm() but that really
doesn't matter if we don't think fat timers are an issue.
Another option is to store the target times in something with more
resolution but only schedule at the second resolution. Then the timers
are always processed within the second like (N, N+1] or something like
that.
I think changes of this order should be considered after push.
mph
