On Wed, 07 Oct 2009 13:20:11 -0400
"Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:

> 
> 
> Michael Hunter wrote:
> > On Wed, 07 Oct 2009 11:13:28 -0400
> > "Anurag S. Maskey" <Anurag.Maskey at Sun.COM> wrote:
> >
> >   
> >> code review request for
> >>        11784 sometimes periodic events don't happen
> >>        http://defect.opensolaris.org/bz/show_bug.cgi?id=11784
> >>
> >>         
> >> http://zhadum.east/export/ws/am223141/checkout-area/nwam1-fixes/webrev/
> >>     
> >
> > Get rid of the local and you won't have to worry about the sign issues.
> >   
> You mean rather than doing rather than calculating "nextalarm", just 
> using "e->event_time" and "now"?

yea, if (e->event_time > now) alarm(e->event_time - now).  Since you
know they are greater then the delta is positive.

> > I dislike that we sometimes push timers forward a second when they
> > should expire within the second and other times have events which have
> > a 0 delta we let run out.  But I can't really think of why it would
> > really matter.  Probably worth explaining in a comment as it is not
> > intuitive at least to me :)
> >   
> If the alarm should go off in this second, then it has already been set 
> (http://defect.opensolaris.org/bz/show_bug.cgi?id=11784#c5).  The 
> granularity is seconds.  Maybe I'm not understanding your comment ...

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 :)

               Michael

> 
> Anurag
> 

Reply via email to