Signals: Software Interrupts for Process Communication

Every system administrator knows the feeling: a runaway process consuming 100% CPU, a hung application refusing to respond, or a network daemon that needs graceful shutdown. In these moments, you reach for a simple yet powerful tool—Ctrl+C, kill, or killall. Behind these commands lies one of the most fundamental and elegant mechanisms in UNIX/POSIX operating systems: signals.

Signals are software interrupts—asynchronous notifications delivered to processes to inform them of events, errors, or explicit requests from users or other processes. They represent the operating system's way of tapping a process on the shoulder and saying, 'Something needs your attention.'

Understanding signals is essential for any systems programmer, DevOps engineer, or backend developer working with UNIX-like systems. They underpin process management, error handling, graceful shutdowns, and inter-process coordination throughout the entire software ecosystem.

A signal is a limited form of inter-process communication used in UNIX, POSIX-compliant, and other UNIX-like operating systems. Unlike pipes, message queues, or shared memory that transmit data between processes, signals communicate the occurrence of an event—they are notifications, not data conduits.

The Formal Definition

Technically, a signal is an asynchronous notification sent to a process (or a specific thread within a process) to notify it that an event has occurred. When a signal is delivered, it interrupts the normal flow of execution and invokes an action—either a default behavior defined by the OS, a custom handler provided by the programmer, or explicit ignoring of the signal.

The Software Interrupt Analogy

Signals are often called software interrupts because they mirror the behavior of hardware interrupts at a higher abstraction level:

Just as hardware interrupts force the CPU to temporarily stop what it's doing and handle an urgent event, signals force a process to temporarily stop and respond to an event—whether that's a termination request, a child process exit, or an arithmetic error.

To truly understand signals, we must appreciate their historical development. The signal mechanism has evolved through three major phases, each addressing limitations of its predecessors.

First Generation: Early UNIX Signals (Version 7 UNIX, 1979)

The original signal mechanism in Version 7 UNIX was remarkably simple—and remarkably problematic. Key characteristics included:

• Unreliable semantics: When a signal handler was invoked, the signal disposition was reset to default (SIG_DFL) before the handler ran. If the same signal arrived during handler execution, the process would be terminated or behave unpredictably.
• No blocking mechanism: A process couldn't temporarily block signals during critical sections.
• Race conditions: The gap between signal arrival and handler registration was a window for lost signals.

This design was prone to subtle bugs that manifested unpredictably, especially under heavy load.

Second Generation: BSD Reliable Signals (4.2BSD, 1983)

Berkeley Software Distribution addressed the reliability issues with significant improvements:

• Persistent handlers: Signal handlers remained installed after invocation.
• Signal masks: Processes could block signals during critical sections using sigblock() and sigsetmask().
• Interrupted system calls: Added the option to automatically restart interrupted system calls.

However, BSD signals were not portable to System V UNIX, creating compatibility nightmares for cross-platform software.

Third Generation: POSIX Signals (IEEE 1003.1, 1988)

The POSIX standard unified signal handling with "reliable signals," combining the best of BSD while ensuring portability:

• sigaction(): The definitive way to install signal handlers with full control over behavior.
• Signal sets: Data structures (sigset_t) to manipulate groups of signals.
• sigprocmask(): Examine and change the blocked signal mask.
• sigpending(): Examine pending (blocked) signals.
• sigsuspend(): Atomically unblock signals and pause.

Modern POSIX signals are the foundation of reliable signal handling and should be used exclusively in production code.

Understanding the internal architecture of signals illuminates how the kernel manages, delivers, and processes these software interrupts.

Per-Process Signal Data Structures

For each process, the kernel maintains several signal-related data structures:

1. Signal Disposition Table: An array (typically 32 or 64 entries) mapping each signal number to its handling action:

   • SIG_DFL (pointer to default handler)
   • SIG_IGN (signal should be ignored)
   • Custom handler function pointer

2. Signal Mask (Blocked Signals): A bitmask indicating which signals are currently blocked from delivery. Blocked signals are held pending until unblocked.

3. Pending Signal Set: A bitmask of signals that have been generated but not yet delivered (either because they're blocked or the process hasn't been scheduled).

4. Signal Action Flags: Per-signal flags controlling behavior (e.g., SA_RESTART for automatic syscall restart, SA_SIGINFO for extended signal information).

Signal Life Cycle: Generation to Delivery

A signal progresses through several states from its origin to its effect on the target process:

Stage 1: Signal Generation A signal is generated when the kernel marks it in the pending set of the target process. Generation sources include:

• Hardware exceptions (SIGFPE for division by zero, SIGSEGV for memory violations)
• Explicit requests via system calls (kill(), raise(), sigqueue())
• Terminal events (SIGINT from Ctrl+C, SIGTSTP from Ctrl+Z)
• Child process state changes (SIGCHLD when a child exits)

Stage 2: Signal Pending Once generated, a signal enters the pending state. If the signal is blocked (in the process's signal mask), it remains pending indefinitely until unblocked. Multiple instances of the same standard signal don't queue—only one is recorded (unlike real-time signals which do queue).

Stage 3: Signal Delivery Delivery occurs when the kernel selects a pending, unblocked signal and takes action. This typically happens:

• When a process returns from kernel mode to user mode
• When a process wakes from a blocking system call
• When sigsuspend() or pause() is used

Stage 4: Signal Handling Upon delivery, one of three actions occurs:

1. Default action: Terminate, terminate+core, stop, continue, or ignore
2. Ignore: Signal is discarded with no effect
3. User handler: Process execution jumps to the registered handler function

Signals can be classified along several dimensions, each revealing different aspects of their purpose and behavior.

By Origin: Synchronous vs. Asynchronous

Synchronous signals are generated as a direct result of the process's own actions—they are predictable consequences of code execution:

• SIGFPE: Arithmetic error (division by zero, overflow)
• SIGSEGV: Invalid memory access (null pointer, out-of-bounds)
• SIGBUS: Bus error (misaligned memory access)
• SIGILL: Illegal instruction (corrupted code, unsupported operation)
• SIGTRAP: Trace/breakpoint trap (debugger support)

Asynchronous signals arrive from external sources, unpredictable from the process's perspective:

• SIGINT: Interrupt from terminal (Ctrl+C)
• SIGTERM: Termination request (from kill command)
• SIGCHLD: Child process status change
• SIGUSR1/SIGUSR2: User-defined signals from other processes
• SIGALRM: Timer expiration

By Default Action

POSIX defines five default actions that signals can trigger:

Standard vs. Real-Time Signals

POSIX distinguishes between two categories based on queuing behavior:

Standard signals (1-31): Have traditional semantics:

• Numbers are platform-specific mappings (SIGKILL is always 9, but SIGUSR1 varies)
• Do NOT queue: Multiple pending instances of the same signal collapse to one
• Delivery order is undefined among multiple pending signals

Real-time signals (SIGRTMIN to SIGRTMAX): Extended semantics:

• Numbers are portable (SIGRTMIN+0, SIGRTMIN+1, etc.)
• DO queue: Each instance is delivered separately
• Delivery is ordered by signal number (lower numbers first)
• Can carry payload data via sigqueue() (an integer and a pointer)

Real-time signals are essential for applications requiring guaranteed delivery counts (e.g., event notifications in multimedia systems).

Understanding how signals are generated—the various pathways by which they come into existence—is fundamental to anticipating and handling them correctly.

Hardware Exceptions

The CPU hardware detects certain error conditions during instruction execution. The kernel translates these hardware exceptions into signals:

These are synchronous signals—they are the immediate consequence of executing a faulty instruction.

Kernel Events

The kernel generates signals in response to events it detects:

• SIGCHLD: Sent to parent when child process terminates, stops, or continues
• SIGPIPE: Writing to a pipe with no readers
• SIGIO: Asynchronous I/O event available
• SIGURG: Out-of-band data on socket
• SIGXCPU: CPU time limit exceeded
• SIGXFSZ: File size limit exceeded

User/Process Requests

Processes explicitly request signal delivery via system calls:

Terminal/Job Control

The terminal driver generates signals based on special characters:

How and when signals are actually delivered to processes involves subtle semantics that profoundly affect program correctness.

The Delivery Window

Signal delivery doesn't happen at arbitrary times—it occurs at well-defined points:

1. Return from kernel to user mode: After a system call, interrupt, or exception completes, the kernel checks for pending signals before resuming user code
2. Wake from sleep: When a process is awakened (e.g., from sleep(), pause(), select()), pending signals are checked
3. Scheduler context switch: When scheduled to run after being preempted

This means a tight computational loop with no system calls may delay signal delivery until the next scheduling opportunity—signals don't magically interrupt pure computation.

System Call Interruption

One of the most practically important aspects of signal handling is how signals interact with blocking system calls. When a signal is delivered while a process is blocked in a system call:

Without SA_RESTART flag:

1. The system call is interrupted
2. Signal handler executes
3. System call returns -1 with errno = EINTR
4. Application must explicitly retry

With SA_RESTART flag:

1. The system call is interrupted
2. Signal handler executes
3. System call automatically restarts (if applicable)
4. Application sees no interruption (usually)

Thread-Directed vs. Process-Directed Signals

In multi-threaded programs, signal targeting becomes nuanced:

Process-directed signals (e.g., from kill(pid, sig)):

• Delivered to any thread that doesn't have the signal blocked
• Exactly one thread handles the signal
• Selection among eligible threads is unspecified (effectively random)

Thread-directed signals (e.g., from pthread_kill(tid, sig)):

• Delivered to the specific target thread
• Thread must not have signal blocked, or it remains pending for that thread

Synchronous signals (SIGSEGV, SIGFPE, etc.):

• Always delivered to the thread that caused the exception
• Cannot be 'redirected' to another thread

The implication: in multi-threaded programs, it's common practice to block signals in all threads except a dedicated 'signal handler' thread. This thread runs a loop calling sigwait() to synchronously receive and process signals, avoiding the complexity of asynchronous handler execution.

Signal masking is the mechanism by which processes temporarily block delivery of specified signals. Blocked signals are not lost—they are held pending and delivered when unblocked. This is essential for implementing critical sections and preventing reentrancy issues.

The Signal Set Interface

POSIX provides a set of functions to manipulate sigset_t data structures:

int sigemptyset(sigset_t *set);      /* Initialize empty set */
int sigfillset(sigset_t *set);       /* Initialize with all signals */
int sigaddset(sigset_t *set, int signum);   /* Add signal to set */
int sigdelset(sigset_t *set, int signum);   /* Remove signal from set */
int sigismember(const sigset_t *set, int signum);  /* Test membership */

sigprocmask(): Controlling the Block Mask

The sigprocmask() system call examines or modifies the process signal mask:

int sigprocmask(int how, const sigset_t *set, sigset_t *oldset);

Automatic Mask During Handler Execution

When a signal handler is invoked via sigaction(), the signal being handled is automatically added to the signal mask for the duration of the handler. This prevents the same signal from interrupting its own handler (reentrancy protection).

Additionally, the sa_mask field of struct sigaction specifies additional signals to block during handler execution:

struct sigaction {
    void (*sa_handler)(int);       /* Handler function */
    void (*sa_sigaction)(int, siginfo_t *, void *);  /* Extended handler */
    sigset_t sa_mask;              /* Signals blocked during handler */
    int sa_flags;                  /* Behavioral flags */
};

This allows you to say: 'While handling SIGTERM, also block SIGINT and SIGQUIT to ensure atomic cleanup.'

sigpending(): Examining Pending Signals

To see which signals are currently pending (generated but blocked):

int sigpending(sigset_t *set);

This is useful for deciding whether to remain in a blocking state or to handle accumulated notifications.

We've established the foundational understanding of signals required for effective Unix/POSIX systems programming. Let's consolidate the core concepts:

What's Next:

With the conceptual foundation established, the next page catalogs the common signals you'll encounter in practice—their purposes, default behaviors, and typical use cases. Understanding the signal vocabulary is essential for debugging, process management, and writing robust system software.