Parent topic: Writing interrupt handlers

The interrupt service routine

Updated: October 28, 2024

Let's look at the ISR itself. In the first example, we'll look at using the InterruptAttach() function. Then, we'll see the exact same thing, except with InterruptAttachEvent().

Using InterruptAttach()
Continuing our example, here's the ISR intHandler(). It looks at the 8250 serial port chip that we assume is attached to HW_SERIAL_IRQ:
Using InterruptAttachEvent()
If we were to recode the example above to use InterruptAttachEvent(), it would look like this:
InterruptAttach() versus InterruptAttachEvent()
This naturally brings us to the question, Why would I use one over the other?
The tradeoffs
So, which function should you use? For low-frequency interrupts, you can almost always get away with InterruptAttachEvent(). Since the interrupts occur infrequently, there won't be a significant impact on overall system performance, even if you do schedule threads unnecessarily. The only time that this can come back to haunt you is if another device is chained off the same interrupt—in this case, because InterruptAttachEvent() masks the source of the interrupt, it'll effectively disable interrupts from the other device until the interrupt source is unmasked. This is a concern only if the first device takes a long time to be serviced. In the bigger picture, this is a hardware system design issue—you shouldn't chain slow-to-respond devices on the same line as high-speed devices.

Related concepts

Interrupt handling (System Architecture)

Writing an Interrupt Handler (QNX Neutrino Programmer's Guide)

Related reference

InterruptAttachEvent()

Parent topic: Writing interrupt handlers