Servicing the hardware

The above discussion may lead you to the conclusion that “level-sensitive is good; edge-triggered is bad.” However, another issue comes into play.

In a level-sensitive environment, your ISR must clear the source of the interrupt (or at least mask it via InterruptMask()) before it completes. (If it didn't, then when the kernel issued the EOI to the PIC, the PIC would then immediately reissue a processor interrupt and the kernel would loop forever, continually calling your ISR code.)

In an edge-triggered environment, there's no such requirement, because the interrupt won't be noticed again until it transits from clear to asserted.

In general, to actually service the interrupt, your ISR has to do very little; the minimum it can get away with is to clear the source of the interrupt and then schedule a thread to actually do the work of handling the interrupt. This is the recommended approach, for a number of reasons:

• Context-switch times between the ISR completing and a thread executing are very small—typically on the order of a few microseconds.
• The type of functions that the ISR itself can execute is very limited (those that don't call any kernel functions, except the ones listed below).
• The ISR runs at a priority higher than any software priority in the system—having the ISR consume a significant amount of processor has a negative impact on the realtime aspects of the QNX Neutrino RTOS.