Menu

Earn Premium with Referrals

Invite your friends and earn Premium rewards through our referral program.

See how it works and start inviting friends.

Signals & Interrupts
OS

Signals & Interrupts

Understand OS signal handling, hardware interrupts, and the top-half/bottom-half pattern.

Signals and interrupts are mechanisms for asynchronous notification. Interrupts come from hardware (device needs attention). Signals come from software (process notification).

Hardware Interrupts

When a device (disk, network card, keyboard) needs attention, it raises an interrupt on the CPU’s interrupt line. The CPU:

  1. Saves current execution state
  2. Looks up the interrupt handler in the Interrupt Vector Table (IVT)
  3. Dispatches to the handler
  4. Restores state and resumes

Interrupts must be handled quickly — devices have strict timing requirements.

Top Half / Bottom Half

The top half is the interrupt handler itself — runs with interrupts disabled (or masked), must be extremely fast. It acknowledges the interrupt and schedules the bottom half.

The bottom half runs later with interrupts enabled — can do heavy lifting (copying data, waking processes). In Linux:

  • SoftIRQs: statically allocated, used for networking, block I/O
  • Tasklets: dynamically allocated, run in softirq context
  • Workqueues: run in process context, can sleep

Signals (Software Interrupts)

Signals are notifications sent to a process about events:

  • Hardware: SIGSEGV (segfault), SIGFPE (math error)
  • User-initiated: SIGINT (Ctrl+C), SIGTSTP (Ctrl+Z)
  • Process-initiated: SIGKILL, SIGTERM, SIGUSR1/2

Signal Disposition

ActionWhat happens
IgnoreSignal is discarded
DefaultProcess terminates, dumps core, or ignores
CatchProcess registers a signal handler function
BlockSignal is pending, delivered when unblocked

Async-Signal-Safe Functions

Only a small set of functions are safe to call from a signal handler (reentrant or atomic). Table from POSIX:

  • write() (not printf!)
  • _exit()
  • signal() itself
  • sigprocmask(), sigsuspend()

Most library functions (malloc, printf, mutex_lock) are not safe — calling them from a signal handler can deadlock or corrupt state.

Q: What is the difference between a signal and an interrupt?

A: An interrupt is generated by hardware and handled by the OS kernel. A signal is generated by software (the kernel or another process) and delivered to a user-space process. Interrupts are asynchronous at the hardware level; signals are asynchronous at the process level.

Q: What is the top-half / bottom-half pattern?

A: The top half is the interrupt handler — runs with interrupts disabled, must be fast. It acknowledges the interrupt and schedules work for later. The bottom half runs with interrupts enabled and does the heavy processing. This minimizes time with interrupts disabled.

Q: Why can’t you call printf() from a signal handler?

A: printf is not async-signal-safe — it uses internal buffers and may acquire locks. If the signal interrupts the program while it’s inside printf, calling printf again can deadlock or corrupt data. Only async-signal-safe functions (like write() and _exit()) are safe.

Q: What is a signal handler?

A: A user-registered function that executes when a specific signal is delivered to the process. Common uses: clean up on SIGTERM, ignore SIGPIPE, handle SIGINT (Ctrl+C) gracefully. Signal handlers have severe restrictions on what they can safely do.

My Private Notes

Notes are auto-saved locally to this device.