A section of code invoked by the hardware whenever an IRQ occurs. It is generally part of the Kernel and usually contained in a device driver. Because they occur asynchronously, invoked by hardware rather than through normal control flow, InterruptHandlers are notoriously hard to write (see RaceCondition). They are also commonly written in AssemblyLanguage because IRQs tend to happen very frequently (try procinfo -n 1 -D on Linux to see counts of the number of interrupts that your Kernel receives; -n 1 means 1 second intervals, -D shows only the differences from one interval to the next).

One specific InterruptHandler is of paramount importance in modern OperatingSystems: the timer IRQ invokes a handler which drives the scheduler that distributes CPU time among tasks. Without this IRQ and its handler, preemptive multitasking would not be possible.

Note that this is different from a Signal handler, which is called by the Kernel through normal control flow means. Note that software can trigger interrupts, and InterruptHandlers sometimes send Signals. The concepts remain distinct, though, despite having many things in common. In general an interupt (IRQ on x86) is to the kernel as a signal is to an application.