• ↑↓ to navigate
  • ↵ to open
  • ⟶ to select
  • ⌘ ⌥ ↵ to open in a panel
  • ←→ to navigate
  • esc to dismiss
⌘ '
keyboard shortcuts

The Problem

When hardware interrupts arrive (keyboard, mouse, network), the CPU needs to know what to do. Without an interrupt handler, the interrupt would be ignored or crash the system.

Core Idea

The OS interrupt handler is a function that runs when a hardware interrupt fires. It reads the scan code (for keyboard) or data (for other devices) and dispatches it to the appropriate driver or application.

How It Works

  1. Interrupt fires: Hardware raises IRQ (e.g., IRQ 1 for keyboard)
  2. CPU jumps: Looks up handler in Interrupt Vector Table
  3. Handler runs:
    • Read data from device (scan code from keyboard)
    • Convert to character (g = scan code 0x22)
    • Determine target application (active window = browser)
  4. Deliver event: Send key event to application

Visual Explanation

G IRQ IRQ 1 (Keyboard) IVT Interrupt Vector Table IRQ 1 → Handler IRQ->IVT Handler OS Interrupt Handler IVT->Handler Browser Browser KeyDown: g Handler->Browser

Key Properties

  • Interrupt Vector Table maps IRQ numbers to handler functions
  • Handlers run in kernel mode (privileged)
  • Must be fast—blocking handler blocks entire system
  • After handler, CPU resumes previous task

Semantic Network

semantic_OS_Interrupt_Handler THIS Os Interrupt Handler REL1 Related Concept THIS--REL1 related REL2 Builds Into THIS--REL2 builds into

Connections

Edge Cases & Gotchas

  • Slow handlers cause system lag (handler blocks everything)
  • Nested interrupts require careful handling
  • Missing handler = interrupt ignored (or panic)
  • Shared IRQs (multiple devices on one IRQ) need demultiplexing