A hardware interrupt lets a device get the CPU’s attention when something happens, such as a key press or data arriving at a network card. It can arrive while another program is running. The CPU stops that program’s execution and jumps to an interrupt handler; the operating system usually handles the event. section 12.1 section 12.1.1
An interruption between two lines
Suppose a Rust program assigns two integers and then adds them. A keyboard interrupt could arrive just before the addition. The CPU handles the interruption, but the program still calculates the sum. What may change is how long the program takes to finish. section 12.2
Figure 12.3 How applications are notified of an interrupt generated from a hardware device. Once the OS has been notified that data is ready, it then directly communicates with the device (in this case, the keyboard) to read the data into its own memory.
Follow the notification from the device through the Programmable Interrupt Controller (PIC) to the CPU. Once notified, the operating system reads the ready data from the device into its own memory. section 12.4
Similar terms describe different layers or origins:
- A signal is an operating-system-level notification to an application, not a hardware interrupt. An operating system can use signals when communicating with applications. section 12.1 section 12.1.1
- An exception arises during CPU processing, such as an invalid memory access. A software interrupt is deliberately generated by a program using a CPU instruction. section 12.1.1 section 12.1
Interrupts can also let an idle CPU avoid busy-waiting. A kernel loop can issue the x86 halt instruction, `hlt`, instead of running continuously with no work to do. The CPU resumes when an interrupt calls for action. section 11.3.1
