44:"/_next/static/chunks/33yus346z0l_n.js" 45:"/_next/static/chunks/2j22cxchii_xx.js" 46:"/_next/static/chunks/0iv56yrji_20j.js" 47:"/_next/static/chunks/32izpn90gvm22.js" 48:"/_next/static/chunks/3j8bi-zu9bqs4.js" 49:"/_next/static/chunks/1z-pox7hqp2x3.js" 4a:"/_next/static/chunks/20w4eaqlekefm.js" 4b:"/_next/static/chunks/1tn-0fivsxsv1.js" 4c:"/_next/static/chunks/09nq57stwzkgf.js" 4d:"/_next/static/chunks/3m1xjj5kw5fie.js" 4e:"/_next/static/chunks/0gafyzg9j9yqj.js" 4f:"/_next/static/chunks/3k2gyg36fnag_.js" 50:"/_next/static/chunks/3bgoyiso1rhn7.js" 51:"/_next/static/chunks/3cstd6xzfli_o.js" 52:"/_next/static/chunks/253gnmj0-cj17.js" 53:"/_next/static/chunks/0hlb44ca7-4a2.js" 54:"/_next/static/chunks/20329i6m_04t6.js" 55:"/_next/static/chunks/40mq7ggq-ozo4.js" 56:"/_next/static/chunks/082jo-0ajazgr.js" 57:"/_next/static/chunks/2ozcrjb_hh74t.js" 58:"/_next/static/chunks/01a-3hvnqu8wl.js" 59:"/_next/static/chunks/05i8en-x14ibi.js" 5a:"/_next/static/chunks/3m0r7x0jt5wm7.js" 5b:"/_next/static/chunks/2k8pepwc4pxns.js" 5c:"/_next/static/chunks/0wa9m1-tphf9u.js" 5d:"/_next/static/chunks/30jdm3dwz834g.js" 5e:"/_next/static/chunks/0k9bl6dipnsvu.js" 5f:"/_next/static/chunks/18ggtgz2yf759.js" 60:"/_next/static/chunks/0i3-eynrkvqi7.js" 61:I[593304,["$2a","$2b","$2c","$2d","$2e","$2f","$44","$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"],"OwnedHydration"] 62:T4f9,The parent-child paradigm for process creation arose from a fundamental insight in operating system design: **creation implies responsibility**. When a process creates another process, the creator naturally assumes oversight responsibilities—managing the child's lifecycle, collecting its termination status, and ensuring proper cleanup when the child concludes execution. ### Why Not Create Processes Independently? One might question why processes need parents at all. Couldn't an operating system simply create processes as independent entities? Theoretically, yes—but this approach creates significant practical problems: 1. **Resource Accounting**: Without a parent, who is responsible for the resources a process consumes? Who reclaims memory if the process crashes? 2. **Termination Status**: When a process completes, its exit status (success, failure, error code) needs to be delivered somewhere. Without a parent, this information is lost. 3. **Privilege Boundaries**: A newly created process needs some initial set of permissions. Inheriting from a parent provides a natural, auditable source of these privileges. 4. **Process Group Organization**: Processes often need to work together. Parent-child relationships provide a natural grouping mechanism.63:T410,#include #include #include /** * Demonstrates the fundamental parent-child relationship * * Key observations: * - Parent and child have different PIDs * - Child's PPID equals parent's PID * - Both execute after fork() but see different return values */ int main() { printf("Before fork(): Process %d ", getpid()); pid_t pid = fork(); // Create child process if (pid < 0) { // Fork failed perror("fork failed"); return 1; } else if (pid == 0) { // Child process executes this branch printf("Child Process: "); printf(" My PID: %d ", getpid()); printf(" My Parent's PID (PPID): %d ", getppid()); printf(" fork() returned to me: %d ", pid); } else { // Parent process executes this branch printf("Parent Process: "); printf(" My PID: %d ", getpid()); printf(" My Child's PID: %d ", pid); printf(" fork() returned to me: %d ", pid); } return 0; }64:T5b0,#include #include #include #include /** * Explores PID/PPID relationships through multiple generations * * This creates a three-generation process tree: * Grandparent (original) -> Parent -> Child */ int main() { printf("=== Generation 0: Grandparent === "); printf("My PID: %d, My PPID: %d (shell/init) ", getpid(), getppid()); pid_t parent_pid = fork(); if (parent_pid == 0) { // First child (becomes "parent" in next generation) printf("=== Generation 1: Parent === "); printf("My PID: %d, My PPID: %d (grandparent) ", getpid(), getppid()); pid_t child_pid = fork(); if (child_pid == 0) { // Second child (grandchild of original) printf("=== Generation 2: Child === "); printf("My PID: %d, My PPID: %d (parent) ", getpid(), getppid()); // Sleep to observe orphan adoption if parent dies first sleep(2); printf("After sleep - My PPID: %d (may change if parent died) ", getppid()); } else if (child_pid > 0) { // Parent waits for grandchild waitpid(child_pid, NULL, 0); } } else if (parent_pid > 0) { // Grandparent waits for parent waitpid(parent_pid, NULL, 0); } return 0; }65:T712,#include #include #include #include #include /** * Demonstrates file descriptor inheritance and shared file offset * * CRITICAL LEARNING: * - Child inherits open file descriptors * - File position is SHARED between parent and child * - Writes interleave unless coordinated */ int main() { // Open file before forking - child will inherit this fd int fd = open("shared_file.txt", O_RDWR | O_CREAT | O_TRUNC, 0644); if (fd < 0) { perror("open"); return 1; } // Write initial content before fork const char* initial = "Initial content from parent before fork "; write(fd, initial, strlen(initial)); pid_t pid = fork(); if (pid == 0) { // Child process // Notice: child did NOT call open() - it inherited fd // Check file position - shared with parent! off_t pos = lseek(fd, 0, SEEK_CUR); printf("Child: Current file position: %ld ", (long)pos); // Write from child const char* child_msg = "Child's contribution "; write(fd, child_msg, strlen(child_msg)); printf("Child: Wrote message, new position: %ld ", (long)lseek(fd, 0, SEEK_CUR)); } else if (pid > 0) { // Parent process wait(NULL); // Wait for child to finish writing // Parent's file position has advanced due to child's write! off_t pos = lseek(fd, 0, SEEK_CUR); printf("Parent: File position after child wrote: %ld ", (long)pos); // Write from parent const char* parent_msg = "Parent's contribution after child "; write(fd, parent_msg, strlen(parent_msg)); close(fd); } return 0; }66:T409,### Environment Variable Inheritance Environment variables represent another critical inherited attribute. They form a simple key-value store that configures program behavior: - **PATH**: Search path for executables - **HOME**: User's home directory - **USER**: Current username - **SHELL**: Default shell - **LD_LIBRARY_PATH**: Dynamic library search path - **Custom Variables**: Application-specific configuration Importantly, the child receives a **copy** of the environment at fork time. Subsequent modifications by either parent or child do not affect the other. ```c // Parent sets environment before fork setenv("MY_CONFIG", "parent_value", 1); pid_t pid = fork(); if (pid == 0) { // Child can read parent's value printf("Child sees: %s ", getenv("MY_CONFIG")); // "parent_value" // Child modifies - parent unaffected setenv("MY_CONFIG", "child_modified", 1); } else { sleep(1); // Parent still sees original value printf("Parent sees: %s ", getenv("MY_CONFIG")); // "parent_value" } ```67:T433,#include #include #include /** * Demonstrates orphan process adoption * * Watch the child's PPID change from parent to init (1) */ int main() { pid_t pid = fork(); if (pid == 0) { // Child process printf("Child (PID %d) started. Original PPID: %d ", getpid(), getppid()); // Wait for parent to die sleep(2); // Check PPID again - should now be 1 (init) printf("Child: After parent died, my new PPID: %d ", getppid()); if (getppid() == 1) { printf("Child: I've been adopted by init! "); } // Continue execution as an orphan sleep(1); printf("Child: Orphan exiting normally. Init will reap me. "); } else if (pid > 0) { // Parent exits immediately, abandoning child printf("Parent (PID %d) exiting, leaving child (PID %d) as orphan ", getpid(), pid); _exit(0); // Parent exits without waiting } return 0; }68:T790,#include #include #include #include #include #include volatile sig_atomic_t child_terminated = 0; /** * SIGCHLD handler for asynchronous child reaping * * CRITICAL: This handler must be async-signal-safe * - Uses only async-signal-safe functions * - Handles multiple children that may terminate simultaneously * - Saves and restores errno */ void sigchld_handler(int sig) { int saved_errno = errno; // Handler may interrupt code that set errno pid_t pid; int status; // Reap ALL terminated children (multiple may have died) while ((pid = waitpid(-1, &status, WNOHANG)) > 0) { // In real code, log or record this information // Here we just set a flag (async-signal-safe) child_terminated++; } errno = saved_errno; // Restore errno } int main() { // Install SIGCHLD handler struct sigaction sa; sa.sa_handler = sigchld_handler; sigemptyset(&sa.sa_mask); sa.sa_flags = SA_RESTART | SA_NOCLDSTOP; // Don't notify on stop/continue if (sigaction(SIGCHLD, &sa, NULL) == -1) { perror("sigaction"); exit(1); } // Create multiple children for (int i = 0; i < 5; i++) { pid_t pid = fork(); if (pid == 0) { // Child: sleep random time (0-3 seconds) then exit srand(getpid()); sleep(rand() % 4); printf("Child %d (PID %d) exiting ", i, getpid()); _exit(i); } } // Parent continues doing work while children run printf("Parent: Working while children run in background... "); for (int i = 0; i < 10; i++) { printf("Parent: Work iteration %d, children reaped so far: %d ", i, child_terminated); sleep(1); } printf("Parent: Total children reaped: %d ", child_terminated); return 0; }69:T753,#include #include /** * Windows process creation demonstration * * Key differences from Unix: * - CreateProcess() combines fork+exec * - Uses HANDLEs instead of PIDs * - Explicit handle inheritance control * - Startup info configures child process */ int main() { STARTUPINFO si; PROCESS_INFORMATION pi; ZeroMemory(&si, sizeof(si)); si.cb = sizeof(si); ZeroMemory(&pi, sizeof(pi)); // Create child process running notepad if (!CreateProcess( NULL, // Application name (NULL = use cmdline) "notepad.exe", // Command line NULL, // Process security attributes NULL, // Thread security attributes FALSE, // Handle inheritance (FALSE = don't inherit) 0, // Creation flags NULL, // Environment (NULL = inherit parent's) NULL, // Current directory (NULL = inherit) &si, // Startup info &pi)) // Process info (receives handles) { printf("CreateProcess failed: %d ", GetLastError()); return 1; } printf("Parent: Created child process "); printf(" Child Process ID: %lu ", pi.dwProcessId); printf(" Child Thread ID: %lu ", pi.dwThreadId); printf(" Process Handle: %p ", pi.hProcess); // Wait for child to complete printf("Waiting for child to exit... "); WaitForSingleObject(pi.hProcess, INFINITE); // Get exit code DWORD exitCode; GetExitCodeProcess(pi.hProcess, &exitCode); printf("Child exited with code: %lu ", exitCode); // Close handles (important: not doing this leaks resources) CloseHandle(pi.hProcess); CloseHandle(pi.hThread); return 0; }42:["$","$L61",null,{"owner":"anonymous","state":{"mutations":[],"queries":[{"dehydratedAt":1792296397534,"state":{"data":{"json":{"id":"seed_39388f8b55d180adc6f90376f0ae2752","slug":"process-creation","category":"Operating Systems","topic":"Process Creation & Termination","title":"Process Creation","description":"Master the mechanisms by which operating systems create new processes. Explore parent-child relationships, process trees, resource sharing strategies, execution options, and address space configurations that form the foundation of process management.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_05af6c8a412f9ad9bd679ee50f840dca","title":"Parent-Child Relationship","order":0,"content":[{"id":"opening-context","title":"The Genesis of Processes","content":[{"data":{"content":"In operating systems, processes are not created in isolation—they emerge from existing processes through a carefully orchestrated mechanism that establishes a **parent-child relationship**. This hierarchical model is not merely an organizational convenience; it is a fundamental architectural decision that shapes resource management, privilege inheritance, termination semantics, and the very identity of every running program on a system.\n\nWhen you launch a web browser, execute a terminal command, or start a background service, you are witnessing the instantiation of this relationship. The shell that interprets your command becomes the **parent**, and the newly created browser or program becomes its **child**. This relationship carries profound implications for how processes share resources, communicate, and ultimately cease to exist."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"By the end of this page, you will understand the complete semantics of parent-child relationships: how they are established, what properties they inherit, how they govern resource sharing, and why this model has become the universal standard across Unix-like, Windows, and real-time operating systems.","variant":"info"},"type":"callout"}]},{"id":"parent-child-paradigm","title":"The Parent-Child Paradigm","content":[{"data":{"content":"$62"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Biological Metaphor","content":"The terminology 'parent' and 'child' deliberately invokes biological reproduction. Just as biological offspring inherit traits from their parents, child processes inherit attributes from their creators. And just as parents bear responsibility for their children, parent processes must properly manage their offspring's lifecycle.","variant":"tip"},"type":"callout"},{"data":{"content":"### The Creation Moment\n\nWhen a parent process creates a child, several critical operations occur atomically from the perspective of the participating processes:\n\n**What the Parent Does:**\n- Requests process creation from the operating system kernel\n- Provides initial parameters (program to execute, arguments, environment)\n- Receives a **Process ID (PID)** representing the new child\n- May optionally wait for the child's completion\n\n**What the Kernel Does:**\n- Allocates a new Process Control Block (PCB)\n- Assigns a unique PID\n- Establishes the parent-child link in process tables\n- Initializes the child's execution context (address space, registers, file descriptors)\n- Schedules the child for execution\n\n**What the Child Receives:**\n- A copy of (or shared access to) the parent's execution context\n- The parent's PID stored as its **Parent PID (PPID)**\n- Inherited file descriptors, environment variables, and permissions\n- Its own unique PID"},"type":"text"},{"data":{"fileName":"parent_child_relationship.c","languages":[{"code":"$63","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"The output demonstrates the core relationship:\n\n```\nBefore fork(): Process 1234\nParent Process:\n My PID: 1234\n My Child's PID: 1235\n fork() returned to me: 1235\nChild Process:\n My PID: 1235\n My Parent's PID (PPID): 1234\n fork() returned to me: 0\n```\n\nNotice how both processes execute the same code after `fork()`, but the return value differentiates them. The parent receives the child's PID, enabling it to track and manage the child. The child receives 0, indicating it is the newly created process."},"type":"text"}],"titleType":"number","titleNumber":1},{"id":"pid-ppid-identity","title":"PID and PPID: Identity and Lineage","content":[{"data":{"content":"Every process in a running system possesses two essential identifiers that define its existence within the process hierarchy:\n\n### Process ID (PID)\n\nThe **Process ID (PID)** is a non-negative integer that uniquely identifies a process within the operating system. PIDs are assigned by the kernel at process creation time and are guaranteed to be unique among all currently running processes.\n\n**Critical Properties of PIDs:**"},"type":"text"},{"data":{"rows":[["**Uniqueness**","No two simultaneously running processes share the same PID"],["**Positive Integers**","PIDs are always positive (0 is reserved for the swapper/null process)"],["**Recycling**","PIDs are reused after a process terminates, but with safeguards"],["**Monotonic Assignment**","Typically assigned sequentially, wrapping around after reaching maximum"],["**32-bit Limit**","Modern systems typically support up to 4,194,304 PIDs (configurable)"]],"headers":["Property","Description"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"PID Recycling Risks","content":"PIDs are recycled after processes terminate. If you store a PID and later try to signal or interact with it, you might accidentally target a completely different process that was assigned the same PID. Always verify process identity through additional means (process start time, file descriptor validation) for security-critical operations.","variant":"warning"},"type":"callout"},{"data":{"content":"### Parent Process ID (PPID)\n\nThe **Parent Process ID (PPID)** is the PID of the process that created the current process. This single link creates the chain that forms the entire process hierarchy.\n\n**Semantics of PPID:**\n\n1. **Set at Creation**: PPID is established when a process is created via `fork()` or equivalent\n\n2. **Immutable Under Normal Circumstances**: A process's parent remains constant throughout its lifetime—with one critical exception\n\n3. **Orphan Reparenting**: If a parent terminates before its child, the child becomes an **orphan**, and its PPID changes to that of the **init** process (PID 1) or a designated subreaper\n\n4. **Queryable**: Any process can retrieve its PPID via `getppid()` system call"},"type":"text"},{"data":{"fileName":"pid_ppid_exploration.c","languages":[{"code":"$64","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"### Special Process IDs\n\nCertain PIDs carry special significance in operating systems:"},"type":"text"},{"data":{"rows":[["**0**","Swapper/Sched/Null","Kernel process for scheduling (not a user process)"],["**1**","init/systemd/launchd","First user-space process, ancestor of all user processes, adopts orphans"],["**2**","kthreadd (Linux)","Parent of all kernel threads"]],"headers":["PID","Name","Role"]},"type":"table"},{"data":{"content":"**The Init Process (PID 1)**\n\nPID 1 occupies a singular position in the operating system hierarchy:\n\n1. **First User Process**: Created directly by the kernel during boot\n2. **Universal Ancestor**: All user processes ultimately trace their lineage to PID 1\n3. **Orphan Adoption**: When a parent dies, its children are reparented to PID 1\n4. **System Shutdown Orchestration**: PID 1 coordinates graceful shutdown\n5. **Immortal (Almost)**: The kernel prevents PID 1 from being killed by normal means; its death triggers kernel panic"},"type":"text"},{"data":{"icon":"Info","title":"Modern Init Systems","content":"Traditional Unix used a simple 'init' program. Modern systems like Linux use 'systemd', macOS uses 'launchd', and Windows has different boot process semantics. Despite implementation differences, the fundamental concept—a root process that anchors the hierarchy—remains universal.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"inheritance-semantics","title":"Inheritance: What Flows from Parent to Child","content":[{"data":{"content":"When a child process is created, it inherits a rich set of attributes from its parent. Understanding precisely what is inherited, what is copied, and what is reset is essential for writing correct concurrent programs.\n\n### Categories of Inheritance\n\nProcess attributes at creation time fall into three categories:\n\n1. **Inherited (Shared or Copied)**: Attributes that pass from parent to child\n2. **Unique to Child**: Attributes that are fresh for each new process\n3. **Reset to Defaults**: Attributes that revert to system defaults\n\nLet's examine each attribute category in detail:"},"type":"text"},{"data":{"rows":[["**Real User ID (UID)**","Copied","Determines ownership; affects permission checks"],["**Effective User ID (EUID)**","Copied","Used for permission checks; may change via setuid binaries"],["**Real/Effective Group ID**","Copied","Similar to UID for group membership"],["**Supplementary Group IDs**","Copied","Additional group memberships"],["**Process Group ID (PGID)**","Copied","For job control; child joins parent's group"],["**Session ID**","Copied","Terminal session membership"],["**Controlling Terminal**","Copied","TTY association for job control"],["**Current Working Directory**","Copied","Path context for relative file operations"],["**Root Directory**","Copied","Changed by chroot; affects path resolution"],["**File Mode Creation Mask (umask)**","Copied","Default permissions for new files"],["**Signal Mask**","Copied","Which signals are blocked"],["**Environment Variables**","Copied","Key-value configuration pairs"],["**Open File Descriptors**","Copied (shared underlying file)","Same file table entries; shared offset"],["**Resource Limits (rlimits)**","Copied","CPU, memory, file size limits"],["**Nice Value**","Copied","Scheduling priority adjustment"]],"caption":"Attributes Inherited from Parent (UNIX/Linux)","headers":["Attribute","Inheritance Type","Notes"]},"type":"table"},{"data":{"rows":[["**Process ID (PID)**","New, unique","Kernel-assigned identifier"],["**Parent Process ID (PPID)**","Parent's PID","Links to creator"],["**Process Times**","Reset to zero","CPU time accounting starts fresh"],["**Pending Signals**","Cleared","No inherited pending signals"],["**File Locks**","Not inherited","Locks held by parent stay with parent"],["**Semaphore Adjustments**","Cleared","POSIX semaphore undo operations"],["**Record Locks**","Not inherited","fcntl() advisory locks"],["**Timer Events**","Not inherited","Interval timers, alarms"],["**Async I/O Operations**","Not inherited","Outstanding async reads/writes"]],"caption":"Attributes Unique to Child Process","headers":["Attribute","Child's Value","Notes"]},"type":"table"},{"data":{"icon":"AlertCircle","title":"File Descriptor Sharing is Reference Sharing","content":"When file descriptors are inherited, parent and child share the SAME underlying file table entry. This means they share the file offset. If the child reads 100 bytes from a file, the parent's file position also advances 100 bytes. This shared state can cause race conditions if not carefully managed.","variant":"warning"},"type":"callout"},{"data":{"fileName":"file_descriptor_inheritance.c","languages":[{"code":"$65","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"$66"},"type":"text"}],"titleType":"number","titleNumber":3},{"id":"responsibility-lifecycle","title":"Responsibility and Lifecycle Management","content":[{"data":{"content":"The parent-child relationship is not merely structural—it carries **obligations**. A parent process has responsibilities toward its children that, if neglected, lead to system-level problems.\n\n### The Wait Obligation\n\nWhen a child process terminates, it does not simply vanish. Instead, it enters a **zombie state**, where it remains in the process table with its exit status preserved, waiting for its parent to collect this information.\n\n**The Zombie Problem:**\n1. Child process exits (calls `exit()` or returns from `main()`)\n2. Kernel preserves minimal state: PID, exit status, resource usage statistics\n3. Child becomes a **zombie** (defunct) process\n4. Parent must call `wait()` or `waitpid()` to collect exit status\n5. Only then is the child's process table entry released\n\n**If the parent never waits:**\n- Zombie accumulates in process table\n- PID remains allocated (cannot be reused)\n- System eventually runs out of available PIDs\n- Fork calls fail with EAGAIN"},"type":"text"},{"data":{"icon":"AlertCircle","title":"Zombie Accumulation is a Resource Leak","content":"Each zombie process consumes a slot in the kernel's process table. While individual zombies use minimal memory, accumulated zombies can exhaust the maximum PID limit (typically 32,768 or higher). Long-running daemons that create children without properly waiting are common culprits of this resource exhaustion.","variant":"error"},"type":"callout"},{"data":{"fileName":"zombie_creation.c","languages":[{"code":"#include \n#include \n#include \n\n/**\n * Demonstrates zombie process creation and reaping\n * \n * Run this and use \"ps aux | grep Z\" to observe zombie state\n */\nint main() {\n pid_t pid = fork();\n \n if (pid == 0) {\n // Child: exit immediately\n printf(\"Child (PID %d) exiting immediately...\n\", getpid());\n _exit(42); // Exit with status 42\n }\n \n // Parent: deliberately don't wait\n printf(\"Parent (PID %d) created child (PID %d)\n\", getpid(), pid);\n printf(\"Sleeping for 30 seconds WITHOUT calling wait()...\n\");\n printf(\"Run: ps aux | grep %d to see zombie state\n\", pid);\n \n sleep(30); // During this time, child is a zombie\n \n // Now properly reap the zombie\n int status;\n waitpid(pid, &status, 0);\n \n if (WIFEXITED(status)) {\n printf(\"Finally reaped child. Exit status was: %d\n\", \n WEXITSTATUS(status));\n }\n \n return 0;\n}","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"### Orphan Adoption\n\nWhat happens when a parent terminates before its child? The child becomes an **orphan**, but the operating system does not leave it unmanaged.\n\n**The Reparenting Mechanism:**\n\n1. Parent process terminates (voluntarily or involuntarily)\n2. Kernel identifies all children of the terminated parent\n3. Each child's PPID is changed to PID 1 (init/systemd)\n4. Init process becomes the adoptive parent\n5. Init's job includes periodically calling `wait()` to reap adopted children\n\nThis mechanism ensures that:\n- No child process is left without a parent\n- Exit statuses of orphaned children are properly collected\n- Zombies from orphaned children don't accumulate\n\n**Subreaper Processes (Linux 3.4+):**\n\nModern Linux allows any process to mark itself as a \"subreaper\" using `prctl(PR_SET_CHILD_SUBREAPER, 1)`. When a process's parent terminates, instead of being adopted by init, it's adopted by the nearest subreaper ancestor. This is useful for container init processes and service managers."},"type":"text"},{"data":{"fileName":"orphan_demonstration.c","languages":[{"code":"$67","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Lightbulb","title":"Orphaning as a Deliberate Strategy","content":"Sometimes orphaning is intentional. The 'double-fork' technique creates a grandchild and lets the middle process exit, making the grandchild an orphan adopted by init. This is a classic Unix idiom for creating daemon processes that are completely detached from any controlling terminal.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"signals-process-groups","title":"Signals and Process Groups","content":[{"data":{"content":"The parent-child relationship intersects with two other critical process management mechanisms: **signals** and **process groups**. Understanding these interactions is essential for building robust process hierarchies.\n\n### Process Groups\n\nA **process group** is a collection of processes that can receive signals together. By default:\n\n- A newly forked child inherits its parent's process group ID (PGID)\n- All processes in a group can be signaled with a single operation\n- Process groups enable job control (foreground/background jobs)\n\n**Job Control Scenario:**\n```\nparent_shell (PGID=1000)\n ├── child1 (PGID=1000) \n ├── child2 (PGID=1000)\n └── child3 (PGID=1000)\n```\n\nWhen you press Ctrl+C in a terminal, SIGINT is sent to the entire foreground process group—all four processes receive it, not just the shell.\n\n### Signal Propagation Rules\n\nSignals interact with parent-child relationships in specific ways:"},"type":"text"},{"data":{"rows":[["**SIGCHLD**","Ignored","Sent to parent when child terminates/stops; enables async child reaping"],["**SIGKILL**","Terminate (uncatchable)","Cannot be blocked or handled; terminates process immediately"],["**SIGSTOP**","Stop (uncatchable)","Cannot be blocked or handled; stops process immediately"],["**SIGTERM**","Terminate","Default termination request; allows cleanup"],["**SIGHUP**","Terminate","Traditionally sent when terminal disconnects; often causes children to terminate"],["**SIGINT**","Terminate","Ctrl+C sends to foreground process group"],["**SIGQUIT**","Core dump","Ctrl+\\\\ sends to foreground process group"]],"caption":"Signal Behavior in Parent-Child Context","headers":["Signal","Default Behavior","Parent-Child Implications"]},"type":"table"},{"data":{"content":"### The SIGCHLD Signal\n\nSIGCHLD is the primary mechanism for asynchronous child management. When a child:\n- Terminates (exits)\n- Is stopped (via SIGSTOP)\n- Is continued (via SIGCONT)\n\nThe kernel sends SIGCHLD to the parent. This enables non-blocking child reaping:"},"type":"text"},{"data":{"fileName":"sigchld_handler.c","languages":[{"code":"$68","label":"C","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"icon":"Info","title":"Signal Handler Safety","content":"Signal handlers execute asynchronously, potentially interrupting any code in the main program. Only 'async-signal-safe' functions can be called from handlers. printf() is NOT safe (though often used in examples); write() is safe. Production code should minimize handler work—set a flag and handle in the main loop.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"cross-platform","title":"Cross-Platform Perspectives","content":[{"data":{"content":"While the parent-child paradigm is universal, its implementation varies across operating systems. Understanding these differences is crucial for writing portable code and for appreciating different design philosophies.\n\n### Windows Process Creation\n\nWindows takes a fundamentally different approach than Unix. Instead of fork-and-exec, Windows uses `CreateProcess()`, which creates a new process and loads a new program in one operation."},"type":"text"},{"data":{"left":[{"data":{"items":["**fork()** duplicates the current process","**exec()** replaces program image (optional)","Separation enables flexible control","Child inherits extensive state","Shallow hierarchy via process groups","PIDs are simple integers"],"title":{"icon":"Code2","text":"Unix/Linux Model","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"right":[{"data":{"items":["**CreateProcess()** creates and loads in one step","No fork() equivalent (without WSL)","Explicit inheritance via SECURITY_ATTRIBUTES","Handles (not integers) identify objects","Job objects for process grouping","Richer initial configuration options"],"title":{"icon":"Code2","text":"Windows Model","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}]},"type":"two-column"},{"data":{"fileName":"windows_create_process.c","languages":[{"code":"$69","label":"C (Windows)","value":"c"}],"showLineNumbers":true},"type":"code"},{"data":{"content":"### Real-Time Operating Systems (RTOS)\n\nReal-time operating systems often have simplified process models focused on determinism:"},"type":"text"},{"data":{"rows":[["**Process Model**","Often single address space with threads (tasks)"],["**Creation Cost**","Minimized for predictable timing"],["**Parent-Child**","May be flat (no hierarchy) or simplified"],["**Fork Semantics**","Rarely supported; creation is explicit"],["**Resource Inheritance**","Typically minimized for isolation"]],"headers":["RTOS Aspect","Typical Approach"]},"type":"table"},{"data":{"content":"**Example: FreeRTOS Task Creation**\n```c\n// FreeRTOS uses tasks, not processes\n// No parent-child hierarchy; tasks are peers\nxTaskCreate(\n vTaskFunction, // Task function\n \"TaskName\", // Name\n STACK_SIZE, // Stack size\n NULL, // Parameters\n PRIORITY, // Priority\n &taskHandle // Handle (output)\n);\n```"},"type":"text"},{"data":{"icon":"Info","title":"Portability Considerations","content":"Libraries like POSIX threads (pthreads) and cross-platform frameworks (Qt, Boost.Process) abstract these differences. However, fundamental semantic differences—like Windows not having fork()—mean some patterns simply don't translate directly. Design with the target platform's capabilities in mind.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"summary","title":"Summary: Parent-Child Relationship","content":[{"data":{"content":"We have explored the foundational concept of parent-child relationships in process creation—a model that underpins virtually all modern operating systems. Let's consolidate the essential knowledge:"},"type":"text"},{"data":{"type":"ordered","items":["**Creation Implies Responsibility** — The parent process is responsible for its children's lifecycle, including collecting exit status via wait()","**PID and PPID Form the Hierarchy** — Every process has a unique PID and knows its parent via PPID, creating a tree rooted at init (PID 1)","**Inheritance is Extensive but Specific** — Children inherit security context, environment, file descriptors, and process group, but not locks, timers, or pending signals","**File Descriptors Share State** — Inherited file descriptors point to the same file table entry; file offsets are shared","**Zombies Require Reaping** — Terminated children become zombies until parents call wait(); neglecting this causes resource leaks","**Orphans Are Adopted** — When parents die, children are reparented to init/systemd, which reaps them","**SIGCHLD Enables Async Management** — Parents can handle child termination asynchronously rather than blocking on wait()"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nThe parent-child relationship creates a structure; the next page explores how these structures form complete **process trees**—the hierarchical arrangement of all processes in a running system. We'll examine how to visualize, traverse, and manage these trees, and understand the implications of tree structure for system administration and process control."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now understand the fundamental parent-child relationship that governs process creation. This relationship—with its inheritance rules, responsibilities, and lifecycle management—is the foundation upon which all process hierarchies are built. Next, we'll see how these relationships combine to form complete process trees.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7}],"isLocked":false},{"id":"seed_2a4067d803c9ef3d97a97cc1a5324343","title":"Process Tree","order":1,"content":null,"isLocked":true},{"id":"seed_aa1554856b374fe3023a20928a495acc","title":"Resource Sharing Options","order":2,"content":null,"isLocked":true},{"id":"seed_7b0db8e9cdd57a8ba2796a71f7d07979","title":"Execution Options","order":3,"content":null,"isLocked":true},{"id":"seed_1b81cf45a800851d21f4b2a04c0661c8","title":"Address Space Options","order":4,"content":null,"isLocked":true}]}},"dataUpdateCount":1,"dataUpdatedAt":1792296397533,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getModule"],{"input":{"slug":"process-creation"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getModule\"],{\"input\":{\"slug\":\"process-creation\"},\"type\":\"query\"}]"},{"dehydratedAt":1792296397534,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792296397531,"error":null,"errorUpdateCount":0,"errorUpdatedAt":0,"fetchFailureCount":0,"fetchFailureReason":null,"fetchMeta":null,"isInvalidated":false,"status":"success","fetchStatus":"idle"},"queryKey":[["learningContent","getProgress"],{"input":{"moduleId":"seed_39388f8b55d180adc6f90376f0ae2752"},"type":"query"}],"queryHash":"[[\"learningContent\",\"getProgress\"],{\"input\":{\"moduleId\":\"seed_39388f8b55d180adc6f90376f0ae2752\"},\"type\":\"query\"}]"},{"dehydratedAt":1792296397534,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792296397531,"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_2a4067d803c9ef3d97a97cc1a5324343"},"type":"query"}],"queryHash":"[[\"feedback\",\"get\"],{\"input\":{\"contentId\":\"seed_2a4067d803c9ef3d97a97cc1a5324343\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792296397534,"state":{"data":{"json":null},"dataUpdateCount":1,"dataUpdatedAt":1792296397531,"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_2a4067d803c9ef3d97a97cc1a5324343"},"type":"query"}],"queryHash":"[[\"feedback\",\"getUserLike\"],{\"input\":{\"contentId\":\"seed_2a4067d803c9ef3d97a97cc1a5324343\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792296397534,"state":{"data":{"json":[]},"dataUpdateCount":1,"dataUpdatedAt":1792296397531,"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_2a4067d803c9ef3d97a97cc1a5324343"},"type":"query"}],"queryHash":"[[\"highlights\",\"getHighlights\"],{\"input\":{\"contentId\":\"seed_2a4067d803c9ef3d97a97cc1a5324343\",\"contentType\":\"LEARNING_PAGE\"},\"type\":\"query\"}]"},{"dehydratedAt":1792296397534,"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_2a4067d803c9ef3d97a97cc1a5324343","minCount":2},"type":"query"}],"queryHash":"[[\"highlights\",\"getPopularHighlights\"],{\"input\":{\"contentId\":\"seed_2a4067d803c9ef3d97a97cc1a5324343\",\"contentType\":\"LEARNING_PAGE\",\"minCount\":2},\"type\":\"query\"}]","promise":"$@6a"}]},"children":"$L6b"}]