Interrupt handling
No matter how much we wish it were so, computers are not infinitely fast. In a realtime system, it's absolutely crucial that CPU cycles aren't unnecessarily spent. But, it is important to balance this with safety, predictable behaviour, and an avoidance of run-time allocation or queueing. QNX OS implements a low-latency path to schedule user threads to handle hardware interrupts.
When a hardware device asserts an interrupt, this will be processed by a Programmable Interrupt Controller (PIC), and if appropriate (not masked, not currently active), it will assert an interrupt on a CPU core. This will cause an exception, and the kernel's exception handler will execute. It will identify the interrupt, and for each thread associated with that interrupt, post an internal semaphore marking the thread as READY, mask the interrupt, and issue an end-of-interrupt (EOI) to the PIC. After the exception handler returns, unblocked thread(s) will be scheduled based on normal thread scheduling rules. A scheduled Interrupt Service Thread (IST) will generally deal with its hardware device, unmask the interrupt, and then block waiting for the next interrupt.