System Programming - Lecture 4, v3 - Signals and interrupts

Summary

The lecture traces asynchronous events from processor hardware through the kernel and into user space. Its central distinction is that interrupts are handled by the processor and kernel, while signals are a process-level mechanism that can represent some kernel events or be sent between processes and threads.

1. Processor interrupts

• Hardware interrupts let devices notify the CPU asynchronously—for example, when a disk or network device has finished work.
  • Repeatedly polling a device wastes CPU and bus resources and does not scale well.
  • With interrupts, the CPU can do other work while the device operates; the device notifies the CPU when it needs attention.
  • An interrupt controller collects device requests, prioritizes them, and forwards them to the CPU. Requests may wait until the CPU can handle them.
• Software interrupts arise from instructions or conditions in the CPU’s execution rather than from an external device. The lecture groups them into:
  • Exceptions or errors, such as division by zero or a page fault. Some can be resolved so the interrupted instruction can be retried; otherwise, the process may be terminated.
  • Traps, which are intentional, such as entering the kernel for a system call or triggering a debugging event.

2. How the kernel dispatches and handles interrupts

• When an interrupt occurs, the CPU saves the interrupted task’s context—including registers and other state—so execution can later resume.
• The CPU uses an Interrupt Descriptor Table (IDT) to find the appropriate handler. The table is in memory, and a special register identifies its starting address. The interrupt number selects the handler.
• The kernel’s immediate handler is called an interrupt service routine (ISR). The lecture also uses IRQ to mean an interrupt request.
• Because interrupt handling is sequential and can delay other device events, the kernel keeps immediate work short:
  • Top half: Runs when the interrupt arrives. It identifies the event, preserves urgent data, and schedules any heavier work.
  • Bottom half: Performs deferred work outside the immediate interrupt context. The lecture describes Linux mechanisms such as softirqs, tasklets, and workqueues.
• The same division of labor is useful in applications: one group of threads can handle I/O while another handles more time-consuming business logic.
• On Linux, /proc/interrupts provides a view of interrupt counts and CPU distribution. The lecture notes that it can help with low-level monitoring and performance investigation.
• Details vary by hardware and kernel. The instructor briefly mentions the more complex interrupt-controller arrangements used in multiprocessor systems but does not cover them in depth.

3. Signals: asynchronous events in user space

• User-space programs cannot directly inspect or handle processor interrupts. The kernel may represent certain events as signals and deliver them to processes.
• Signals are more targeted than processor interrupts: they concern particular processes or threads. They can also be sent by programs, so they are not limited to hardware-related events.
• Signals have numbered constants, commonly with the SIG prefix. The lecture points to the system’s signal documentation for the available list.
• Many signals can be caught with a custom handler, ignored, or left to their default action. SIGKILL and SIGSTOP cannot be caught or blocked.
• Examples discussed include:
  • SIGINT, commonly associated with Ctrl-C in a terminal.
  • SIGALRM, delivered after a specified number of seconds.
  • SIGSEGV, associated with invalid memory access.
  • SIGFPE, associated with arithmetic faults such as division by zero.
  • SIGTRAP, associated with breakpoints or tracing.

4. Why the signal() interface is discouraged

The lecture first demonstrates the older signal() interface, then explains its limitations:

• Its behavior has varied across systems and implementations.
• Historically, a handler could be reset after a signal, creating a window in which another signal might not be handled as intended.
• It does not provide the signal-blocking controls needed for many synchronization patterns.
• The lecture cautions against relying on it in multithreaded programs.

A signal handler can interrupt a program at almost any point, including while it is in a system call or modifying shared state. This can cause interrupted calls, deadlocks, corruption, or other undefined behavior. For example, calling malloc, free, or printf from a handler can be unsafe if the interrupted code was already using the heap or the library’s internal state.

The handler should therefore be treated as a restricted execution context. The lecture recommends consulting the platform’s list of async-signal-safe functions (on Linux, the signal(7) manual page) rather than assuming ordinary library functions are safe.

5. Signal handling APIs and practices covered

• sigaction() is presented as the preferred replacement for signal().
  • It installs a handler and can return the previous action.
  • It can use either a simple handler or a more informative handler that receives siginfo_t, which can include details such as the faulting address.
  • Its mask controls which signals are blocked while the handler runs. By default, the signal being handled is blocked during its own handler, avoiding recursive handling of that same signal.
  • Flags can change behavior, including allowing recursive delivery, using an alternate stack, or resetting the handler after delivery.
• sigprocmask() changes the signal mask for the current thread. The lecture emphasizes that masks are thread-specific even though signal-handler dispositions are process-wide.
  • A blocked signal is held pending rather than discarded.
  • If several instances of the same ordinary signal arrive while it is blocked, they may be coalesced; they are not necessarily kept as separate queued events.
  • Helpers such as sigemptyset, sigfillset, sigaddset, sigdelset, and sigismember operate on signal sets.
  • sigpending() checks which signals are pending.
• sigsuspend() addresses a race in the pattern “unblock a signal, then wait for it.” It temporarily applies a signal mask and waits atomically, avoiding a signal arriving between those two steps.
• sigaltstack() configures a separate stack for signal handling. This can be useful when the normal thread stack is exhausted or when a handler needs a separate stack. The lecture’s example allocates suitably sized memory, registers it as the alternate stack, enables its use for the handler, and disables it before freeing that memory.
• kill() sends a chosen signal to a process; despite its name, the signal need not be fatal. raise() sends a signal to the calling process or thread. pause() waits for a signal. The instructor notes that alarm() has limited usefulness for many modern timeout patterns.

6. Signal handlers and stack control

• Returning normally from a handler resumes the interrupted execution. If the underlying fault remains, the interrupted instruction may be attempted again; for a persistent fault such as invalid memory access, this can lead to repeated signals.
• The lecture also demonstrates nonlocal jumps from a signal handler. It distinguishes ordinary setjmp/longjmp from sigsetjmp/siglongjmp: the latter can preserve and restore the signal mask, which matters when a jump exits a handler while a signal is temporarily blocked.
• These mechanisms are low-level and require care; they do not make arbitrary signal-handler operations safe.

7. Signals as a coroutine implementation technique

The lecture’s final extended example explores using signals and alternate stacks to build stackful coroutines in C:

1. Give each coroutine its own stack.
2. Use an alternate signal stack and a self-directed signal to enter a handler on that stack.
3. Save the coroutine’s execution context with a jump buffer.
4. Jump between the saved coroutine context and the code managing the coroutines.

The instructor contrasts this with stackless approaches based on jumps. Ordinary function calls rely on stack state, including return addresses; jumping back into a function after its stack has been reused can therefore fail. A custom stack per coroutine avoids some of these problems, but building a usable coroutine runtime still requires scheduling and synchronization machinery.

Coroutines are generally cooperative: they must yield control voluntarily. Kernel-scheduled threads are preemptive: the scheduler can interrupt them. The lecture observes that signal-driven preemption in user space is technically possible, but frequent signals can collide with library operations such as heap allocation, making the approach hazardous without substantial runtime support.

Main takeaways

• Hardware interrupts provide an efficient way for devices to notify the CPU without constant polling.
• The kernel saves and restores task context, dispatches handlers, and defers lengthy work so interrupt handling remains responsive.
• Signals provide asynchronous event delivery in user space, but they are not a general-purpose message queue.
• Prefer sigaction() and deliberate signal-mask management over the older signal() interface.
• Signal handlers are a restricted and potentially dangerous context; many ordinary library functions are unsafe there.
• Alternate stacks and jump-based context switching enable low-level techniques, but they demand careful handling of stacks, masks, and shared state.

Speakers and sources featured

• Speaker: One unnamed lecturer or presenter; no guest speakers are identified in the subtitles.
• Technical references and sources mentioned:
  • Linux signal documentation, particularly man 7 signal.
  • Linux /proc/interrupts.
  • Processor and kernel concepts, including interrupt controllers, the IDT, ISRs, and deferred interrupt handling.
  • The leap_coro library, cited by the lecturer as an example coroutine implementation.
  • Boost signal-handling facilities, mentioned as a possible C++ wrapper or API.