Losing interrupts?

[David F. Carlson]

In article <NELSON.88Sep29160014 at sun.soe.clarkson.edu>, nelson at sun.soe.clarkson.edu (Russ Nelson) writes:
> I notice that the section of the Runtime System manual that deals with
> Writing Device Drivers and interrupts says that interrupts can be
> lost.  Is this true?  If so, does Microport consider it a bug (i.e.
> will it be fixed?)
> --russ (nelson at clutx [.bitnet | .clarkson.edu])

The problem is not Microport's:  its the d*mn IBM PC/AT interrupt
controller (aka Intel 8259.)  The problem is not solvable in software
alone, thus Microport is not to blame.  It was nice of them to tell
you that it is a problem though so you won't pull your hair out trying
to figure our why.  It is good device driver design to *assume* you
will lose a critical interrupt so your design can cover its ass with
a polling.  If the "next" interrupt time is known, a callout can be done
to "simulate" the missing interrupt.  The rule for device drivers anywhere
is that there is no such thing as reliable interrupts.

-- 
David F. Carlson, Micropen, Inc.
micropen!dave at ee.rochester.edu

"The faster I go, the behinder I get." --Lewis Carroll