45:"/_next/static/chunks/33yus346z0l_n.js" 46:"/_next/static/chunks/2j22cxchii_xx.js" 47:"/_next/static/chunks/0iv56yrji_20j.js" 48:"/_next/static/chunks/32izpn90gvm22.js" 49:"/_next/static/chunks/3j8bi-zu9bqs4.js" 4a:"/_next/static/chunks/1z-pox7hqp2x3.js" 4b:"/_next/static/chunks/20w4eaqlekefm.js" 4c:"/_next/static/chunks/1tn-0fivsxsv1.js" 4d:"/_next/static/chunks/09nq57stwzkgf.js" 4e:"/_next/static/chunks/3m1xjj5kw5fie.js" 4f:"/_next/static/chunks/0gafyzg9j9yqj.js" 50:"/_next/static/chunks/3k2gyg36fnag_.js" 51:"/_next/static/chunks/3bgoyiso1rhn7.js" 52:"/_next/static/chunks/3cstd6xzfli_o.js" 53:"/_next/static/chunks/253gnmj0-cj17.js" 54:"/_next/static/chunks/0hlb44ca7-4a2.js" 55:"/_next/static/chunks/20329i6m_04t6.js" 56:"/_next/static/chunks/40mq7ggq-ozo4.js" 57:"/_next/static/chunks/082jo-0ajazgr.js" 58:"/_next/static/chunks/2ozcrjb_hh74t.js" 59:"/_next/static/chunks/01a-3hvnqu8wl.js" 5a:"/_next/static/chunks/05i8en-x14ibi.js" 5b:"/_next/static/chunks/3m0r7x0jt5wm7.js" 5c:"/_next/static/chunks/2k8pepwc4pxns.js" 5d:"/_next/static/chunks/0wa9m1-tphf9u.js" 5e:"/_next/static/chunks/30jdm3dwz834g.js" 5f:"/_next/static/chunks/0k9bl6dipnsvu.js" 60:"/_next/static/chunks/18ggtgz2yf759.js" 61:"/_next/static/chunks/0i3-eynrkvqi7.js" 62:I[593304,["$2a","$2b","$2c","$2d","$2e","$2f","$45","$46","$47","$48","$49","$4a","$4b","$4c","$4d","$4e","$4f","$50","$51","$52","$53","$54","$55","$56","$57","$58","$59","$5a","$5b","$5c","$5d","$5e","$5f","$60","$61"],"OwnedHydration"] 63:T4d4,### 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.64:T41c,flowchart TB subgraph Process["Process P (PID=1234)"] direction TB PCB["Process Control Block"] subgraph SignalData["Signal Data Structures"] direction LR Disp["Signal Disposition Table --- SIGINT → handler_func SIGTERM → SIG_DFL SIGPIPE → SIG_IGN SIGUSR1 → custom_handler"] Mask["Signal Mask (blocked signals) --- Bit 2: SIGQUIT ✓ Bit 17: SIGCHLD ✓"] Pend["Pending Signals --- Bit 9: SIGKILL Bit 15: SIGTERM"] end PCB --> SignalData end subgraph Kernel["Kernel Space"] SigGen["Signal Generation (kill syscall, exception, etc.)"] SigQueue["Signal Queue (for real-time signals)"] Delivery["Signal Delivery Logic"] end SigGen --> SigQueue SigQueue --> Delivery Delivery --> Pend style Process fill:#1a1a2e,stroke:#4a90d9,stroke-width:2px style Kernel fill:#0d0d1a,stroke:#d94a4a,stroke-width:2px style SignalData fill:#2d2d44,stroke:#4ad94a,stroke-width:1px65:T5a6,### 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 function66:T553,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)67:T632,#include #include #include #include volatile sig_atomic_t alarm_fired = 0; void alarm_handler(int sig) { alarm_fired = 1; } ssize_t safe_read(int fd, void *buf, size_t count) { ssize_t result; /* * Production-quality read: handles interruption properly. * This pattern is essential for robust signal-aware code. */ while ((result = read(fd, buf, count)) == -1 && errno == EINTR) { /* * read() was interrupted by a signal. * Check if we should continue or abort based on application logic. */ if (alarm_fired) { fprintf(stderr, "Read interrupted by alarm - timeout! "); return -1; /* Application-level timeout */ } /* Otherwise, retry the read */ } return result; } int main() { char buffer[256]; struct sigaction sa; /* Install alarm handler WITHOUT SA_RESTART */ sa.sa_handler = alarm_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; /* No SA_RESTART - intentionally allow EINTR */ sigaction(SIGALRM, &sa, NULL); printf("Reading from stdin (5 second timeout)... "); alarm(5); /* Generate SIGALRM in 5 seconds */ ssize_t bytes = safe_read(STDIN_FILENO, buffer, sizeof(buffer)); alarm(0); /* Cancel pending alarm */ if (bytes > 0) { printf("Read %zd bytes: %.*s ", bytes, (int)bytes, buffer); } else if (alarm_fired) { printf("No input within timeout "); } else { perror("read"); } return 0; }68:T74e,#include #include #include /* * Demonstrates using signal masking to protect critical sections. * Signals blocked during critical work are delivered afterward. */ volatile int shared_counter = 0; volatile int signal_count = 0; void sigint_handler(int sig) { signal_count++; printf(" [Handler] SIGINT received (total: %d) ", signal_count); } void critical_section() { sigset_t block_mask, old_mask; /* Create mask with SIGINT */ sigemptyset(&block_mask); sigaddset(&block_mask, SIGINT); /* * Block SIGINT during critical section. * Save old mask for restoration. */ printf("Entering critical section (SIGINT blocked)... "); if (sigprocmask(SIG_BLOCK, &block_mask, &old_mask) == -1) { perror("sigprocmask"); return; } /* * Critical work - SIGINT is deferred, not lost. * Press Ctrl+C multiple times - signals pending. */ for (int i = 0; i < 5; i++) { shared_counter++; printf(" Critical work step %d (counter=%d) ", i + 1, shared_counter); sleep(1); /* Slow enough to try Ctrl+C */ } /* * Restore original mask - pending signals now delivered. * Note: Multiple SIGINTs during block collapse to ONE delivery. */ printf("Exiting critical section (SIGINT unblocked)... "); if (sigprocmask(SIG_SETMASK, &old_mask, NULL) == -1) { perror("sigprocmask"); return; } printf("Counter final value: %d, signals received: %d ", shared_counter, signal_count); } int main() { struct sigaction sa; sa.sa_handler = sigint_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = 0; sigaction(SIGINT, &sa, NULL); printf("Press Ctrl+C during critical section... "); critical_section(); return 0; }69:T42f,### 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: ```c 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): ```c int sigpending(sigset_t *set); ``` This is useful for deciding whether to remain in a blocking state or to handle accumulated notifications.43:["$","$L62",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792309634365,"state":{"data":{"json":{"id":"seed_73aebd74ca7d61da7158211a7af2ea89","slug":"signals","category":"Operating Systems","topic":"Signals","title":"Signals: Software Interrupts for Process Communication","description":"Master the signal mechanism in UNIX/POSIX systems—the fundamental asynchronous notification system that enables processes to respond to events, handle errors, and communicate. Learn signal concepts, common signals, handlers, signal sending, and reliability considerations.","difficulty":"INTERMEDIATE","estimatedMinutes":90,"pages":[{"id":"seed_ae3e59be4d863eb4061ac7f488c3dccc","title":"Signal Concepts: Understanding Software Interrupts","order":0,"content":[{"id":"opening-hook","title":"The Invisible Messengers","content":[{"data":{"content":"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**.\n\nSignals 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.'\n\nUnderstanding 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."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the signal mechanism at a deep level: its historical origins, architectural design, delivery semantics, and how it fits into the broader landscape of inter-process communication. You'll gain the conceptual foundation needed to implement robust signal handling in production systems.","variant":"info"},"type":"callout"}]},{"id":"what-are-signals","title":"What Are Signals?","content":[{"data":{"content":"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.\n\n### The Formal Definition\n\nTechnically, 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.\n\n### The Software Interrupt Analogy\n\nSignals are often called **software interrupts** because they mirror the behavior of hardware interrupts at a higher abstraction level:"},"type":"text"},{"data":{"rows":[["Source","Hardware device (keyboard, disk, network)","Kernel, process, or user action"],["Target","CPU execution context","Process execution context"],["Effect","Suspends current instruction, jumps to ISR","Suspends process execution, invokes handler"],["Timing","Asynchronous, unpredictable","Asynchronous, unpredictable"],["Purpose","Device communication","Event notification"]],"headers":["Aspect","Hardware Interrupt","Software Signal"]},"type":"table"},{"data":{"content":"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."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Key Insight: Signals Are Finite State","content":"Unlike message-based IPC where you can send arbitrary data, traditional UNIX signals carry no payload—they only indicate that 'signal X occurred.' The signal number itself (an integer from 1 to 31 in classic UNIX, extended in POSIX) is the complete message. This simplicity enables extremely efficient delivery but limits expressiveness compared to other IPC mechanisms.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":1},{"id":"historical-context","title":"Historical Context and Evolution","content":[{"data":{"content":"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.\n\n### First Generation: Early UNIX Signals (Version 7 UNIX, 1979)\n\nThe original signal mechanism in Version 7 UNIX was remarkably simple—and remarkably problematic. Key characteristics included:\n\n- **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.\n- **No blocking mechanism**: A process couldn't temporarily block signals during critical sections.\n- **Race conditions**: The gap between signal arrival and handler registration was a window for lost signals.\n\nThis design was prone to subtle bugs that manifested unpredictably, especially under heavy load."},"type":"text"},{"data":{"code":"/* Classic unreliable signal handling - DO NOT USE */\n#include \n#include \n\nvoid sigint_handler(int sig) {\n /* DANGER: Handler resets to SIG_DFL here! */\n /* Must re-register immediately, but window exists for lost signals */\n signal(SIGINT, sigint_handler); /* Re-register handler */\n printf(\"Caught SIGINT\n\");\n}\n\nint main() {\n signal(SIGINT, sigint_handler);\n while (1) {\n pause(); /* Wait for signal */\n }\n return 0;\n}\n\n/*\n * PROBLEM: Between handler invocation and re-registration,\n * a second SIGINT will terminate the process (default behavior).\n * This race condition was a fundamental flaw in V7 UNIX signals.\n */","variant":"default","fileName":"unreliable_signal_example.c","showLineNumbers":true},"type":"code"},{"data":{"content":"$63"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Legacy Code Alert","content":"You will still encounter `signal()` in legacy code and tutorials. While POSIX environments typically implement `signal()` with reliable semantics (BSD-style), the behavior varies by platform. Always use `sigaction()` for new code—it's explicit, portable, and reliable. The `signal()` function should be considered deprecated for serious applications.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"signal-architecture","title":"Signal Architecture Deep Dive","content":[{"data":{"content":"Understanding the internal architecture of signals illuminates how the kernel manages, delivers, and processes these software interrupts.\n\n### Per-Process Signal Data Structures\n\nFor each process, the kernel maintains several signal-related data structures:\n\n1. **Signal Disposition Table**: An array (typically 32 or 64 entries) mapping each signal number to its handling action:\n - `SIG_DFL` (pointer to default handler)\n - `SIG_IGN` (signal should be ignored)\n - Custom handler function pointer\n\n2. **Signal Mask (Blocked Signals)**: A bitmask indicating which signals are currently blocked from delivery. Blocked signals are held pending until unblocked.\n\n3. **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).\n\n4. **Signal Action Flags**: Per-signal flags controlling behavior (e.g., `SA_RESTART` for automatic syscall restart, `SA_SIGINFO` for extended signal information)."},"type":"text"},{"data":{"height":"500px","mermaidSyntax":"$64"},"type":"mermaid-excalidraw"},{"data":{"content":"$65"},"type":"text"},{"data":{"icon":"Info","title":"Critical Architectural Detail","content":"Signal delivery is fundamentally asynchronous. The exact moment a signal interrupts your code is unpredictable—it could be between any two machine instructions. This asynchrony is the source of both signals' power (immediate event notification) and their danger (race conditions, non-reentrant code issues).","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":3},{"id":"signal-categories","title":"Signal Categories and Classification","content":[{"data":{"content":"Signals can be classified along several dimensions, each revealing different aspects of their purpose and behavior.\n\n### By Origin: Synchronous vs. Asynchronous\n\n**Synchronous signals** are generated as a direct result of the process's own actions—they are predictable consequences of code execution:\n- `SIGFPE`: Arithmetic error (division by zero, overflow)\n- `SIGSEGV`: Invalid memory access (null pointer, out-of-bounds)\n- `SIGBUS`: Bus error (misaligned memory access)\n- `SIGILL`: Illegal instruction (corrupted code, unsupported operation)\n- `SIGTRAP`: Trace/breakpoint trap (debugger support)\n\n**Asynchronous signals** arrive from external sources, unpredictable from the process's perspective:\n- `SIGINT`: Interrupt from terminal (Ctrl+C)\n- `SIGTERM`: Termination request (from `kill` command)\n- `SIGCHLD`: Child process status change\n- `SIGUSR1/SIGUSR2`: User-defined signals from other processes\n- `SIGALRM`: Timer expiration"},"type":"text"},{"data":{"rows":[["**Synchronous**","SIGSEGV, SIGFPE, SIGILL, SIGBUS","Process's own execution (errors)","Deterministic—same bug reproduces"],["**Asynchronous (User)**","SIGINT, SIGTERM, SIGUSR1","User input, explicit kill requests","Unpredictable timing"],["**Asynchronous (Kernel)**","SIGCHLD, SIGPIPE, SIGIO","Kernel-detected events","Depends on external state"],["**Timer-based**","SIGALRM, SIGVTALRM, SIGPROF","Interval timer expiration","Scheduled but async to code"]],"caption":"Signal Classification by Origin","headers":["Category","Examples","Cause","Predictability"]},"type":"table"},{"data":{"content":"### By Default Action\n\nPOSIX defines five default actions that signals can trigger:"},"type":"text"},{"data":{"rows":[["**Terminate**","Process exits immediately","SIGTERM, SIGINT, SIGKILL, SIGHUP"],["**Terminate + Core Dump**","Process exits and writes core file","SIGQUIT, SIGABRT, SIGSEGV, SIGFPE"],["**Ignore**","Signal has no effect","SIGCHLD, SIGURG (default on most systems)"],["**Stop**","Process execution is suspended","SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU"],["**Continue**","Resume stopped process","SIGCONT"]],"headers":["Default Action","Description","Example Signals"]},"type":"table"},{"data":{"content":"### Standard vs. Real-Time Signals\n\nPOSIX distinguishes between two categories based on queuing behavior:\n\n**Standard signals (1-31)**: Have traditional semantics:\n- Numbers are platform-specific mappings (SIGKILL is always 9, but SIGUSR1 varies)\n- Do NOT queue: Multiple pending instances of the same signal collapse to one\n- Delivery order is undefined among multiple pending signals\n\n**Real-time signals (SIGRTMIN to SIGRTMAX)**: Extended semantics:\n- Numbers are portable (SIGRTMIN+0, SIGRTMIN+1, etc.)\n- DO queue: Each instance is delivered separately\n- Delivery is ordered by signal number (lower numbers first)\n- Can carry payload data via `sigqueue()` (an integer and a pointer)\n\nReal-time signals are essential for applications requiring guaranteed delivery counts (e.g., event notifications in multimedia systems)."},"type":"text"},{"data":{"icon":"Lightbulb","title":"Design Consideration","content":"When designing systems that rely on signal-based notifications, prefer real-time signals if you need: (1) guaranteed delivery of each occurrence, (2) payload data transfer, or (3) defined ordering. Standard signals are suitable for 'at least once' notifications where the count doesn't matter—like termination requests or interrupt handling.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"signal-generation","title":"Signal Generation Mechanisms","content":[{"data":{"content":"Understanding how signals are generated—the various pathways by which they come into existence—is fundamental to anticipating and handling them correctly.\n\n### Hardware Exceptions\n\nThe CPU hardware detects certain error conditions during instruction execution. The kernel translates these hardware exceptions into signals:"},"type":"text"},{"data":{"rows":[["Division by zero","SIGFPE","Integer division by zero, floating-point errors"],["Invalid memory access","SIGSEGV","NULL pointer dereference, stack overflow, buffer overflow"],["Bus error","SIGBUS","Misaligned memory access, non-existent physical address"],["Illegal instruction","SIGILL","Corrupted executable, JIT compilation errors"],["Breakpoint","SIGTRAP","Debugger breakpoints, single-stepping"]],"headers":["Hardware Exception","Resulting Signal","Common Cause"]},"type":"table"},{"data":{"content":"These are synchronous signals—they are the immediate consequence of executing a faulty instruction."},"type":"text"},{"data":{"code":"#include \n#include \n#include \n\n/* Handler for SIGSEGV - demonstrates synchronous signal */\nvoid sigsegv_handler(int sig) {\n fprintf(stderr, \"Caught SIGSEGV: Invalid memory access\n\");\n fprintf(stderr, \"This handler was invoked synchronously - the process\n\");\n fprintf(stderr, \"tried to access memory it doesn't own.\n\");\n exit(1); /* Cannot resume from SIGSEGV safely */\n}\n\nint main() {\n struct sigaction sa;\n sa.sa_handler = sigsegv_handler;\n sigemptyset(&sa.sa_mask);\n sa.sa_flags = 0;\n sigaction(SIGSEGV, &sa, NULL);\n \n /* Intentionally trigger SIGSEGV */\n int *ptr = NULL;\n printf(\"About to dereference NULL pointer...\n\");\n *ptr = 42; /* SIGSEGV generated here - synchronously */\n \n printf(\"This line will never execute\n\");\n return 0;\n}\n\n/*\n * Key insight: SIGSEGV is generated at the exact instruction that\n * attempts the invalid access. The signal handler runs immediately,\n * and the faulting instruction never completes.\n */","variant":"default","fileName":"hardware_exception_example.c","showLineNumbers":true},"type":"code"},{"data":{"content":"### Kernel Events\n\nThe kernel generates signals in response to events it detects:\n\n- **`SIGCHLD`**: Sent to parent when child process terminates, stops, or continues\n- **`SIGPIPE`**: Writing to a pipe with no readers\n- **`SIGIO`**: Asynchronous I/O event available\n- **`SIGURG`**: Out-of-band data on socket\n- **`SIGXCPU`**: CPU time limit exceeded\n- **`SIGXFSZ`**: File size limit exceeded\n\n### User/Process Requests\n\nProcesses explicitly request signal delivery via system calls:"},"type":"text"},{"data":{"rows":[["`kill(pid, sig)`","Send signal to process","Process termination, notifications"],["`raise(sig)`","Send signal to self","Self-notification, testing"],["`sigqueue(pid, sig, val)`","Send with payload (real-time)","Data-carrying notifications"],["`pthread_kill(tid, sig)`","Send to specific thread","Thread-level control"],["`killpg(pgrp, sig)`","Send to process group","Session-wide signals"]],"headers":["System Call","Description","Use Case"]},"type":"table"},{"data":{"content":"### Terminal/Job Control\n\nThe terminal driver generates signals based on special characters:"},"type":"text"},{"data":{"rows":[["Ctrl+C","SIGINT","Interrupt foreground process group"],["Ctrl+\\","SIGQUIT","Quit with core dump"],["Ctrl+Z","SIGTSTP","Stop foreground process"],["(bg→fg transition)","SIGCONT","Resume stopped process"],["(bg read from terminal)","SIGTTIN","Stop background process"],["(bg write to terminal)","SIGTTOU","Stop background process (if configured)"]],"headers":["Keystroke","Signal","Effect"]},"type":"table"},{"data":{"icon":"Info","title":"Signal Generation vs. Delivery","content":"A crucial distinction: signal *generation* marks the signal as pending for the target process; signal *delivery* is when the action is taken. If the signal is blocked, it remains pending indefinitely. SIGKILL and SIGSTOP are special—they cannot be blocked, caught, or ignored, ensuring administrators always have termination control.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"signal-delivery-semantics","title":"Signal Delivery Semantics","content":[{"data":{"content":"$66"},"type":"text"},{"data":{"code":"$67","variant":"default","fileName":"eintr_handling.c","showLineNumbers":true},"type":"code"},{"data":{"content":"### Thread-Directed vs. Process-Directed Signals\n\nIn multi-threaded programs, signal targeting becomes nuanced:\n\n**Process-directed signals** (e.g., from `kill(pid, sig)`):\n- Delivered to any thread that doesn't have the signal blocked\n- Exactly one thread handles the signal\n- Selection among eligible threads is unspecified (effectively random)\n\n**Thread-directed signals** (e.g., from `pthread_kill(tid, sig)`):\n- Delivered to the specific target thread\n- Thread must not have signal blocked, or it remains pending for that thread\n\n**Synchronous signals** (SIGSEGV, SIGFPE, etc.):\n- Always delivered to the thread that caused the exception\n- Cannot be 'redirected' to another thread\n\nThe 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."},"type":"text"},{"data":{"icon":"AlertCircle","title":"Multi-Threaded Signal Pitfall","content":"If you don't explicitly manage the signal mask in multi-threaded programs, signals may be delivered to unpredictable threads. This can cause race conditions, especially if handlers access shared data. Always design your signal strategy at application startup: block signals in workers, and use a dedicated thread or `signalfd()` for synchronous handling.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"signal-blocking","title":"Signal Blocking and Masking","content":[{"data":{"content":"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.\n\n### The Signal Set Interface\n\nPOSIX provides a set of functions to manipulate `sigset_t` data structures:\n\n```c\nint sigemptyset(sigset_t *set); /* Initialize empty set */\nint sigfillset(sigset_t *set); /* Initialize with all signals */\nint sigaddset(sigset_t *set, int signum); /* Add signal to set */\nint sigdelset(sigset_t *set, int signum); /* Remove signal from set */\nint sigismember(const sigset_t *set, int signum); /* Test membership */\n```\n\n### sigprocmask(): Controlling the Block Mask\n\nThe `sigprocmask()` system call examines or modifies the process signal mask:\n\n```c\nint sigprocmask(int how, const sigset_t *set, sigset_t *oldset);\n```"},"type":"text"},{"data":{"rows":[["SIG_BLOCK","Add signals in `set` to current mask"],["SIG_UNBLOCK","Remove signals in `set` from current mask"],["SIG_SETMASK","Replace current mask with `set`"]],"headers":["how","Effect"]},"type":"table"},{"data":{"code":"$68","variant":"default","fileName":"critical_section.c","showLineNumbers":true},"type":"code"},{"data":{"content":"$69"},"type":"text"},{"data":{"icon":"Lightbulb","title":"Blocking Pattern for Robustness","content":"A common robust pattern: block signals at the start of a complex operation, perform the operation atomically (from the signal perspective), then unblock and handle any pending signals. Use `sigsuspend()` to atomically unblock and wait if you need to pause for signals after a critical section.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary-key-takeaways","title":"Summary: Signal Concepts","content":[{"data":{"content":"We've established the foundational understanding of signals required for effective Unix/POSIX systems programming. Let's consolidate the core concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**Signals are software interrupts** — They notify processes of events asynchronously, interrupting normal execution flow to invoke handlers.","**Three actions are possible** — Default (terminate, stop, ignore), explicit ignore (SIG_IGN), or custom handler function.","**Historical evolution matters** — Use POSIX `sigaction()` exclusively; legacy `signal()` has unreliable, non-portable semantics.","**Signals are categorized by origin** — Synchronous (from process actions like SIGSEGV) vs. asynchronous (from external sources like SIGINT).","**Signal lifecycle: generation → pending → delivery** — Blocked signals remain pending; delivery occurs at specific kernel-to-user transitions.","**Standard signals don't queue** — Multiple pending instances of the same signal collapse to one; real-time signals do queue.","**Signal masks protect critical sections** — Use `sigprocmask()` to temporarily block signals during sensitive operations.","**Multi-threaded programs need explicit signal strategy** — Block in workers, handle in dedicated thread to avoid unpredictability."],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nWith 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."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete: Signal Concepts","content":"You now understand signals as software interrupts—their architecture, categories, lifecycle, and blocking mechanisms. This foundation prepares you to work with specific signals and implement robust handlers in production systems.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_af19186d4ae7974138e3d7dacce0ddac","title":"Common Signals: The UNIX Signal Vocabulary","order":1,"content":null,"isLocked":true},{"id":"seed_e78f8894db83fac0aa4cc5fa8e57f20d","title":"Signal Handlers: Installing and Implementing Correctly","order":2,"content":null,"isLocked":true},{"id":"seed_04820d03c131490b35774360dd345eea","title":"Sending Signals: Inter-Process Signal Transmission","order":3,"content":null,"isLocked":true},{"id":"seed_206490b3de4d2ac4bcc3a03baaa69e39","title":"Signal Reliability: Edge Cases and Robustness","order":4,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792309634357,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"signals"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"signals\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309634365,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309634355,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_73aebd74ca7d61da7158211a7af2ea89"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_73aebd74ca7d61da7158211a7af2ea89\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309634365,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309634355,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","get"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_af19186d4ae7974138e3d7dacce0ddac"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_af19186d4ae7974138e3d7dacce0ddac\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309634365,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792309634355,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["feedback","getUserLike"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_af19186d4ae7974138e3d7dacce0ddac"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_af19186d4ae7974138e3d7dacce0ddac\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309634365,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792309634355,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["highlights","getHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_af19186d4ae7974138e3d7dacce0ddac"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_af19186d4ae7974138e3d7dacce0ddac\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792309634365,"state":{"data":"$undefined","dataUpdateCount":0,"dataUpdatedAt":0,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"pending","fetchStatus":"fetching"},"queryKey":[["highlights","getPopularHighlights"],{"input":{"contentType":"LEARNING_PAGE","contentId":"seed_af19186d4ae7974138e3d7dacce0ddac","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_af19186d4ae7974138e3d7dacce0ddac\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6a"}]},"children":"$L6b"}]