An interrupt is a signal that tells the processor to stop what it is doing, save just enough of its state to resume later, and jump to a special routine called an interrupt handler. When the handler finishes, the processor restores the saved state and continues exactly where it left off. This mechanism lets a CPU respond to events that happen at unpredictable times, such as a key being pressed, a network packet arriving, or a timer expiring, without having to constantly check for them.
The alternative to interrupts is polling, where the processor repeatedly asks each device whether it needs attention. Polling wastes effort: most of the time the answer is no, and the CPU burns cycles looping instead of doing useful work. Interrupts invert this. The device stays quiet until it actually has something to report, then raises an interrupt request, an IRQ, which pulls the processor in only when there is real work to do. This is why interrupt-driven input and output is the foundation of any responsive, multitasking system.
Architectures distinguish interrupts from exceptions, though the dispatch mechanism is shared. An interrupt is typically external and asynchronous, generated by hardware independent of the instruction the CPU happens to be running. An exception is synchronous, raised by the instruction stream itself, for example a divide-by-zero, an invalid opcode, or a page fault when accessing memory that is not currently mapped. Software can also deliberately trigger the mechanism: a software interrupt or trap instruction is the classic way a user program requests a service from the kernel. Intel’s “Intel 64 and IA-32 Architectures Software Developer’s Manual” devotes its third volume to system programming, which “describes the operating-system support environment,” including “interrupt and exception handling,” and defines how each is delivered and serviced.
The processor decides which handler to run by consulting an interrupt vector. Each interrupt or exception is assigned a number, and that number indexes into a table of handler addresses, the interrupt vector table or, on x86, the interrupt descriptor table. ARM systems use an equivalent mechanism, holding the base of the vector table in a system register so that each exception type has a fixed offset from that base. When an interrupt of a given number arrives, the hardware looks up the corresponding entry and transfers control there, which is how a single raised signal becomes a call to the right piece of operating-system code.
Interrupts are also central to how an operating system stays in control. A periodic timer interrupt is what lets a kernel take the processor back from a running program to schedule another one, the heartbeat of preemptive multitasking. Because handling an interrupt means switching into privileged mode and saving and restoring processor state, the kernel must manage registers, the stack, and timing carefully. The humble interrupt thus underlies device drivers, system calls, fault handling, and the very ability of a computer to do many things at once.