A computer can spend millions of cycles calculating, copying data, rendering graphics and waiting for storage while a person is doing something as ordinary as pressing a key. Yet the moment that key is pressed, the processor can be notified that new input has arrived without Windows constantly asking the keyboard whether anything happened.
That mechanism is the hardware interrupt.
The keyboard does not literally force the processor to abandon every operation it is performing. The processor finishes the part of its current instruction that must be completed, accepts an interrupt when the relevant conditions allow it, saves enough execution state to resume its previous work, and transfers control to an interrupt handler. On a modern Windows PC, the process involves the keyboard device, its controller or interface, the interrupt routing hardware, the CPU's interrupt architecture and several layers of Windows drivers.
The interrupt controller is the traffic manager in the middle of that chain. It receives interrupt requests, determines where they should go and participates in deciding when the processor can accept them.
This mechanism is one of the reasons a computer can remain responsive while hundreds of different hardware events are happening in the background.
The keyboard does not wait for the processor to ask whether a key was pressed
A naive model of keyboard input would be simple polling.
The processor could repeatedly ask the keyboard:
"Did someone press a key?"
Then:
"Now?"
"And now?"
And again.
That approach would work in principle, but it would waste processor time. The CPU would spend part of its attention repeatedly checking devices that may have nothing new to report.
Interrupts reverse the relationship.
Instead of the processor constantly asking whether something happened, the device can signal that something requires attention.
A keyboard press therefore starts with an event at the input device. Depending on the keyboard technology and the path used by the system, the keyboard's electronics detect the key transition and communicate input data through its interface. The relevant controller or device logic then causes an interrupt request to be delivered through the platform's interrupt-routing mechanism.
The processor does not need to stare at the keyboard continuously.
It can work on something else until the hardware produces an interrupt that the system is prepared to accept.
That change from polling to notification is the fundamental idea.
The interrupt controller is the traffic manager between hardware and CPU
A modern PC has many possible sources of interrupts.
A storage controller can need attention. A network device can receive data. A timer can expire. A USB controller can report activity. A graphics device can signal an event. A keyboard or another human-interface device can produce input.
If every device could simply interrupt the processor without a routing mechanism, the CPU would have no organized way to distinguish the sources.
Modern x86 systems use the Advanced Programmable Interrupt Controller architecture, commonly known as APIC. The architecture includes local APIC functionality associated with processors and interrupt-routing logic that can direct device interrupts toward an appropriate processor.
The local APIC maintains information about pending interrupts and their service state. Intel's architecture documentation describes interrupt requests being accepted by the local APIC, placed into interrupt-request state and then dispatched according to interrupt priority and processor priority.
That means the interrupt controller is not merely an electrical switch.
It participates in a software-visible architecture that determines how interrupt requests are represented, prioritized and delivered.
This is especially important on a multi-core processor. A modern CPU package may have many logical processors, and the operating system can configure interrupt affinity so that particular interrupts are handled by selected processors or distributed across processors.
A keyboard interrupt is therefore not simply "the keyboard interrupted the CPU".
It is better described as:
keyboard hardware generated an event -> the platform generated an interrupt request -> interrupt-routing hardware delivered it -> a processor accepted the interrupt -> the Windows interrupt handling path began processing the event.
The processor does not literally throw away its current work
The phrase "the CPU drops everything" is useful as an intuition, but it is technically inaccurate.
Suppose one CPU core is executing a thread that is calculating something. A keyboard interrupt becomes pending.
The processor cannot simply destroy the current instruction and start keyboard processing from the middle of nowhere. It has an architectural mechanism for recognizing the interrupt at an appropriate boundary, saving the execution state needed to return to the interrupted code and transferring control to the interrupt handler.
The interrupted thread has not disappeared.
Its registers and execution context can be preserved so that execution can continue after interrupt handling reaches the point where normal thread execution resumes.
This is one reason interrupts can feel instantaneous to a human without actually stopping the entire computer.
The interruption is local to the processor handling it, and the handler is expected to be very short.
On a multi-core system, other processors can continue executing their own work. Even on a single-core system, interrupt processing normally occupies only a small amount of execution time before ordinary work resumes.
The computer therefore does not freeze every time a key is pressed.
It briefly changes what the relevant processor is doing.
The interrupt controller decides which requests are ready to be delivered
Interrupts are not all treated as identical.
The processor has mechanisms for managing interrupt priority. The APIC architecture includes priority information that can prevent lower-priority interrupts from being delivered while the processor is operating at a higher interrupt priority.
Intel documentation describes the processor priority class as a threshold for interrupt delivery. A pending interrupt whose priority is not high enough can remain pending until the processor becomes able to accept it.
This is important because hardware can generate interrupts faster than the processor can handle them.
Imagine a system receiving network traffic while also servicing storage, timers and input devices. If every interrupt immediately interrupted every other piece of processing with no priority rules, the processor could spend an excessive amount of time switching between handlers.
Interrupt architecture provides a structured way to control that traffic.
The local APIC can maintain pending interrupt information, and the processor can accept eligible interrupts according to its priority state.
The exact priority values and routing details are far more complicated than a simple "keyboard always wins" rule.
A keyboard event is important because interactive input should be handled promptly, but that does not mean a keyboard interrupt automatically outranks every possible event in every situation.
The first Windows driver response is deliberately small
Once Windows reaches the device's interrupt service routine, the driver is not supposed to perform a huge amount of work at the highest interrupt level.
That would be dangerous for system responsiveness.
Microsoft's Windows driver documentation describes an interrupt service routine, or ISR, as a routine that should do what is necessary to acknowledge or dismiss the interrupt, save the volatile information that must be preserved and typically queue a deferred procedure call for additional processing.
The reason is simple.
An ISR executes in a special interrupt context. At that level, many ordinary operations are unavailable or undesirable. The handler must return quickly so that the processor can continue servicing the rest of the system.
This creates a two-stage model.
The first stage reacts to the hardware event.
The second stage performs more of the processing at a lower interrupt request level.
Windows calls that second mechanism a Deferred Procedure Call, or DPC.
The distinction is crucial for understanding why the phrase "the keyboard interrupts the processor" does not mean that the entire keyboard subsystem runs at the instant the electrical event occurs.
The interrupt is the urgent notification.
The rest of the work can be deferred.
The ISR catches the urgent part and the DPC handles more of the work
The relationship between ISR and DPC is one of the most useful concepts in Windows hardware architecture.
An ISR needs to react quickly. It may read information from the device, acknowledge the interrupt source and preserve data that could otherwise be lost.
Then it can schedule a DPC.
A DPC runs later at DISPATCH_LEVEL. Microsoft documents this as a normal part of interrupt-driven Windows driver design. The DPC can complete more of the I/O processing without keeping the processor in the more restrictive ISR context.
This is a clever compromise.
The hardware gets a fast response.
The driver does not have to perform every operation at the highest interrupt priority.
The operating system can return to other work sooner.
For a keyboard, the details depend on the hardware and driver stack. Windows has historically included a low-level keyboard port driver for legacy PS/2-style paths and HID-related infrastructure for modern human-interface devices. The Windows driver documentation exposes keyboard ISR and packet-queue mechanisms as part of that architecture.
The important principle is independent of the exact hardware path:
hardware event -> interrupt service -> input data is captured -> deferred processing -> higher-level input handling.
The character that eventually appears in an application is therefore several steps removed from the first electrical event.
A key press does not directly produce the letter shown on screen
Pressing the "A" key does not mean that the keyboard physically sends the Windows text character "A" directly into the application.
The keyboard reports an input event according to its protocol and device architecture. The operating system and input stack then interpret that event.
There is an important difference between a physical key event and the final text character.
A key can produce different results depending on modifier state. Shift can change the result. Caps Lock can affect alphabetic input. Keyboard layout can map the physical key position to different characters. Applications can also receive keyboard events for purposes other than text entry.
This means the interrupt controller has no concept of the letter "A".
Neither does the CPU's interrupt mechanism.
The interrupt system knows that a hardware event requires attention. The driver stack handles the device-specific information. Higher layers interpret the input according to the operating system's input model.
By the time an application receives a character or keyboard event, the original hardware interrupt has already done its small but essential job.
The keyboard interrupt has a priority, but that does not mean the keyboard is the most important device
The wording "the processor drops everything" can create another misconception.
Interrupts have priorities, but the keyboard is not given a magical status that lets it interrupt anything at any time.
The processor can mask or defer classes of interrupts. Higher-priority interrupts can interrupt lower-priority interrupt handling. Non-maskable interrupts and other special classes have separate architectural behavior.
Intel's APIC documentation describes pending interrupt requests being represented in interrupt-request registers and dispatched based on priority and processor state.
This allows the system to keep control even when many hardware events occur at once.
Imagine a workstation copying data from a fast storage device while a network adapter receives packets and the user presses a key.
Several interrupt sources may be active.
The interrupt controller helps route these requests and the CPU's interrupt logic determines which eligible interrupt is handled according to the current priority state.
The keyboard event does not need to be the single most important event in the machine.
It only needs to be delivered promptly enough for the user to experience immediate input.
Multiple CPU cores change the picture completely
On an old single-core processor, an interrupt necessarily interrupted the only executing processor.
Modern systems are different.
A processor can have many logical CPUs, and the operating system can distribute work across them. Interrupts can also be routed according to affinity and system configuration.
This means a keyboard interrupt handled on one logical processor does not necessarily stop a workload running on another logical processor.
Suppose one core is processing a demanding calculation while another core is running a thread that receives the keyboard-related interrupt and its associated driver processing.
The system can continue making progress on both kinds of work.
The interrupt architecture is therefore part of the machinery that allows modern operating systems to scale beyond a single execution stream.
The phrase "the CPU stops what it is doing" becomes increasingly misleading as the number of logical processors grows.
More precisely, a particular processor can temporarily switch from ordinary execution into interrupt handling.
The rest of the machine does not necessarily stop.
Interrupt affinity determines where hardware events are handled
On a multi-core system, the operating system has to decide where interrupts should go.
This is known as interrupt affinity.
The exact configuration can depend on hardware, firmware, Windows policy, device drivers and system topology. Some high-throughput devices benefit from distributing interrupt processing across multiple processors.
A keyboard generally produces a tiny amount of traffic compared with a high-speed network interface, so the performance problem is very different.
A network adapter can generate a large stream of events and may use multiple interrupt vectors and receive queues. A keyboard produces relatively infrequent human-generated input.
The architecture nevertheless needs to support both.
The same fundamental interrupt machinery can route a small keyboard event and a high-volume device event, while the driver and hardware determine how much processing follows.
This is one reason the interrupt controller is better thought of as infrastructure rather than a keyboard-specific component.
Interrupts are essential because polling does not scale well
Polling has legitimate uses. A system can deliberately check a device at intervals, and many hardware and software mechanisms use polling or hybrid strategies in appropriate circumstances.
But using constant polling for every hardware event would be inefficient.
Consider a computer with a keyboard, mouse, network interface, storage controller, audio device, USB controller, timers and other peripherals.
If the processor had to repeatedly ask each device whether something happened, the amount of checking would grow with the number of devices.
Interrupts reverse the burden.
A device that needs attention can signal the system.
The processor can spend most of its time executing ordinary workloads rather than repeatedly asking inactive hardware for updates.
This is particularly valuable when events are unpredictable.
A keyboard might remain idle for several seconds. There is no benefit in constantly interrogating it hundreds of thousands of times during that interval.
An interrupt lets the system sleep, calculate or perform other work until the event actually occurs.
The interrupt controller is not the same thing as the keyboard controller
The terminology can be confusing because several different components can be described as controllers.
A keyboard has electronics that scan keys and produce input information.
A platform can have a keyboard interface or controller.
The system also has interrupt-routing hardware.
The processor has local interrupt functionality.
Windows has keyboard and HID drivers.
These are not all the same thing.
The interrupt controller's job is to participate in interrupt delivery. It does not interpret whether a particular physical key is "A", "Enter" or "Shift".
The keyboard device and its driver stack are responsible for the input data.
This separation is important because it allows the same interrupt architecture to serve many different hardware devices.
The controller does not need to understand the meaning of every event.
It only needs to provide a reliable mechanism for delivering interrupt requests to the processor system.
Modern keyboards can use a very different path from the classic PS/2 model
Many explanations of keyboard interrupts begin with the traditional PS/2 keyboard and an i8042-style controller. That model is useful historically and can still describe some hardware paths, but it should not be treated as the universal architecture of every modern keyboard.
USB keyboards use the USB host controller and USB device protocol. Wireless keyboards introduce another layer between the physical keys and the operating system. Windows HID infrastructure then provides a common framework for human-interface devices.
The interrupt event that matters at the CPU level can therefore originate from a USB controller rather than directly from a classic keyboard controller.
The high-level idea remains the same.
Something in the hardware stack detects or receives new input.
That hardware path causes an interrupt.
Windows services the interrupt and processes the input.
The application eventually receives the appropriate input event.
This is why the concept of "keyboard interrupt" is useful as a conceptual shortcut, but it should not be interpreted as meaning that every keyboard physically connects to the same interrupt source.
The CPU uses an interrupt vector to find the right handler
Once the processor accepts an interrupt, it needs to know where to transfer control.
This is where interrupt vectors enter the architecture.
An interrupt is associated with a vector that identifies the corresponding entry in the processor's interrupt mechanism. The processor uses that information to transfer execution into the appropriate handler path.
The vector is not a human-readable label such as "keyboard".
It is part of the low-level architecture that allows the operating system to connect hardware interrupt events with the correct software handling path.
This mechanism is one reason the interrupt system can support many different event sources.
The CPU does not need a special physical pathway for every driver.
It needs an architecture that can identify the interrupt and enter the appropriate system handler.
Modern APIC systems can support a large vector space. Intel documentation describes the APIC's interrupt request and in-service registers as representing interrupt vectors, with reserved low vector ranges and a broad set of vectors available for interrupt delivery.
The operating system manages this complexity so that device drivers can register the interrupt handling mechanisms they need without requiring application programmers to understand the electrical details.
Windows does not let an interrupt handler run forever
An interrupt service routine that never returns would effectively hold the processor hostage.
That would be catastrophic for system responsiveness.
Windows therefore imposes strict rules on interrupt handling. Microsoft recommends that an ISR do only the work necessary at its interrupt level and defer additional processing to a DPC when possible.
DPC routines themselves also have restrictions. They execute at DISPATCH_LEVEL and cannot perform operations that require waiting in the same way ordinary thread code can. Microsoft recommends keeping DPC execution brief and delegating work that does not need to remain at that level.
This layered design is what makes interrupts practical on a busy operating system.
The system can respond quickly without forcing every hardware event to execute a large amount of code before normal work can resume.
A keyboard press might therefore cause a chain of short operations rather than one enormous interrupt routine.
The first part reacts immediately.
The next part processes the event.
The higher-level input system then delivers the result to the application that needs it.
What actually happens between pressing a key and seeing a letter
The entire journey can now be described without the misleading idea that the CPU simply abandons everything.
A key changes state inside the keyboard.
The keyboard's electronics report the event through its connection.
The relevant hardware path receives or detects the new input.
An interrupt request is generated for the appropriate hardware interface.
The platform's interrupt-routing mechanism directs the request toward a processor.
The processor accepts the interrupt when its current interrupt state allows it.
The CPU transfers execution into the operating system's interrupt handling path.
The device driver's ISR performs the urgent work and captures the information that must not be lost.
The ISR can queue a DPC for additional processing.
The driver and Windows input stack process the keyboard data.
The operating system interprets the event according to keyboard layout, modifier state and input rules.
The appropriate application eventually receives a keyboard event or text input.
Only then does the application decide what that input means in its own context.
The remarkable part is not that one of these steps is individually complicated.
The remarkable part is how quickly the entire chain can happen while the computer continues doing everything else.
A delayed keyboard response can reveal problems far below the keyboard itself
If a keyboard feels slow, the keyboard is not necessarily the source of the problem.
Interrupt processing can be affected by driver behavior, excessive DPC activity, CPU contention, firmware problems, USB controller issues, power-management behavior and other system-level conditions.
A driver that spends too much time in an ISR or DPC can reduce responsiveness for other work sharing the processor.
Microsoft's driver guidance specifically warns that DPC routines should execute only briefly because while a DPC is running at DISPATCH_LEVEL, ordinary threads on that processor cannot run.
This is one reason professional Windows diagnostics can examine ISR and DPC execution time when investigating latency problems.
A keyboard can therefore be perfectly functional while the operating system around it is temporarily unable to process input promptly.
The symptom appears at the keyboard.
The cause can be elsewhere.
Interrupt handling is a compromise between speed and control
The fastest possible response would be to let every device interrupt the processor immediately and perform all required work at once.
That would also be a terrible operating-system design.
The system needs to balance responsiveness, priority, synchronization and throughput.
Interrupts provide the fast notification mechanism.
ISRs provide the urgent first response.
DPCs provide a lower-priority context for additional processing.
Threads and work items can perform operations that require an even less restrictive execution environment.
This layered structure allows Windows to respond to hardware quickly without allowing every device to monopolize the processor.
The keyboard is an excellent example because the event is easy for humans to understand.
A person presses a key.
The computer reacts.
Behind that simple interaction is a carefully controlled hierarchy of hardware and software priorities.
The interrupt controller makes the "instant" response possible
The next time a key appears on screen almost immediately after it is pressed, there is no need to imagine the processor abandoning a huge calculation and starting from zero.
The CPU has an interrupt architecture specifically designed for this situation.
The keyboard generates or causes a hardware event.
The platform routes the corresponding interrupt request.
The processor accepts the interrupt according to its current state and priority.
Windows executes a short interrupt service routine.
Additional work is deferred when appropriate.
The input stack turns device data into an event that an application can understand.
The interrupted work then continues.
The interrupt controller is therefore less like a button that stops the processor and more like a highly organized emergency dispatch system. It makes sure that a hardware event can reach the processor without requiring the operating system to constantly poll every device.
That is why a single key press can cut through a busy computer so quickly.
The processor is not abandoning its work.
It is temporarily giving the hardware event exactly the amount of attention required, then returning to what it was doing before.