At Wed, 27 Feb 2002 02:14:44 +0000 (UTC), "Rafal Boni" wrote:
> The following patch fixes it, but I'm still not sure what the right
> thing to do is if the interrupt is so delayed that we'll miss the next
> one -- I currently simply schedule the next clock interrupt the fixed
> time from *now* to avoid complexity in figuring out how far we'd fallen
> behind and adding in the right fugde factor.

I think i've seen the following different methods used, at least:

* figure out how many ticks should were missed, and call the
appropriate interrupt-delivery function that many times.  (i.e.,
bursty tick delivery when you have missed ticks.)

* call the interrupt-delivery once, but have it call back into the
clock handling code to see exactly how much time has elapsed.  (i.e.,
ticks come no closer than 'compare interval' apart, but clock time
doesn't drift because the tick handling code looks to see how much
time has actually elapsed rather than assuming it's 'compare
interval'.)


I dunno, that may be incorrect recollection or understanding of the
code that i've seen, as well.  8-)



cgd