6a:T7b2,/* * File Descriptor Sharing After fork() * * CRITICAL: While file descriptors are duplicated, they share * the underlying file table entry (file offset, status flags). * * PARENT PROCESS CHILD PROCESS * ┌──────────────┐ ┌──────────────┐ * │ fd table │ │ fd table │ * │ fd[3] ──────────┐ ┌────── fd[3] │ * └──────────────┘ │ │ └──────────────┘ * │ │ * ▼ ▼ * ┌─────────────────┐ * │ File Table Entry│ ← SHARED! * │ - file offset │ * │ - status flags │ * │ - vnode pointer │ * └─────────────────┘ * │ * ▼ * ┌─────────────────┐ * │ v-node │ * │ (inode in-core) │ * └─────────────────┘ * * CONSEQUENCE: If parent reads 100 bytes, the offset advances * for BOTH parent and child! */ #include #include #include #include int main() { int fd = open("test.txt", O_RDONLY); char buffer[10]; pid_t pid = fork(); if (pid == 0) { // Child: read first 10 bytes read(fd, buffer, 10); printf("Child read, offset now at: %ld ", lseek(fd, 0, SEEK_CUR)); _exit(0); } else { wait(NULL); // Wait for child // Parent: offset has moved! printf("Parent offset: %ld ", lseek(fd, 0, SEEK_CUR)); // If child read 10 bytes, parent's offset is also at 10! } close(fd); return 0; }6b:T9ce,/* * fork() in Multi-threaded Programs - DANGER ZONE * * Scenario: Thread A holds a mutex, Thread B calls fork() * * BEFORE FORK: * ┌─────────────────────────────────┐ * │ Process │ * │ ┌──────────┐ ┌──────────────┐ │ * │ │ Thread A │ │ Thread B │ │ * │ │ (holding │ │ (calls fork) │ │ * │ │ mutex) │ │ │ │ * │ └──────────┘ └──────────────┘ │ * │ mutex: LOCKED │ * └─────────────────────────────────┘ * * AFTER FORK (in child): * ┌─────────────────────────────────┐ * │ Child Process │ * │ ┌──────────────┐ │ * │ │ Thread B' │ ← Only thread │ * │ │ │ Thread A is │ * │ └──────────────┘ GONE! │ * │ mutex: LOCKED ← But who │ * │ will │ * │ unlock? │ * └─────────────────────────────────┘ * * RESULT: Deadlock in child if it tries to acquire mutex! */ #include #include #include pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER; void* thread_func(void* arg) { pthread_mutex_lock(&lock); printf("Thread A: Holding lock forever... "); sleep(100); // Hold lock pthread_mutex_unlock(&lock); return NULL; } int main() { pthread_t thread; pthread_create(&thread, NULL, thread_func, NULL); sleep(1); // Let thread A acquire lock pid_t pid = fork(); // Thread B (main) forks if (pid == 0) { // Child: Thread A doesn't exist, but mutex is locked! printf("Child: Trying to acquire lock... "); pthread_mutex_lock(&lock); // DEADLOCK! printf("Child: Got lock! "); // Never reached pthread_mutex_unlock(&lock); } return 0; } /* * SOLUTIONS: * 1. Use pthread_atfork() to handle locks * 2. Avoid fork() in multi-threaded programs * 3. Only call async-signal-safe functions post-fork, then exec() */6c:T7b0,/* * Visualization of the Fork Point * * Before fork(): * │ main() * │ printf("Before fork") * │ pid = fork() ← Execution splits HERE * ╱ ╲ * ╱ ╲ * ╱ ╲ * CHILD PARENT * pid = 0 pid = child's PID * (returns) (returns) * │ │ * │ │ * Both continue from the SAME instruction * (the one after fork() returns) */ #include #include #include int main() { printf("Before fork: pid = %d ", getpid()); // Printed once // ═══════════════════════════════════════════════ // THE FORK POINT // ═══════════════════════════════════════════════ pid_t pid = fork(); // ═══════════════════════════════════════════════ // From this point forward, there are TWO processes // executing this SAME code, independently. // The ONLY difference is the value of 'pid'. // ═══════════════════════════════════════════════ // This line executes TWICE: once in parent, once in child printf("After fork: pid = %d, fork returned = %d ", getpid(), pid); // Both processes have their own copy of all variables int x = 42; x = x + getpid(); // Different value in each process! printf("x = %d in process %d ", x, getpid()); return 0; } /* * Possible output (order may vary): * * Before fork: pid = 1234 * After fork: pid = 1234, fork returned = 1235 * After fork: pid = 1235, fork returned = 0 * x = 1276 in process 1234 * x = 1277 in process 1235 */6d:Td06,/* * Complete fork() Semantics Demonstration * Compile: gcc -o fork_demo fork_demo.c * Run: ./fork_demo */ #include #include #include #include #include #include /* Global variable - separate copy in each process after fork */ int global_counter = 0; int main() { /* Automatic (stack) variable */ int stack_var = 100; /* Heap-allocated variable */ int *heap_var = malloc(sizeof(int)); *heap_var = 200; /* Buffer for I/O demonstration */ char shared_buffer[64] = "Initial content"; printf("=== Before fork() === "); printf("PID: %d, PPID: %d ", getpid(), getppid()); printf("global_counter addr: %p, value: %d ", (void*)&global_counter, global_counter); printf("stack_var addr: %p, value: %d ", (void*)&stack_var, stack_var); printf("heap_var addr: %p, value: %d (arr at %p) ", (void*)heap_var, *heap_var, (void*)&heap_var); printf(" "); /* === THE FORK === */ pid_t pid = fork(); /* Error handling */ if (pid < 0) { perror("fork failed"); exit(EXIT_FAILURE); } /* CHILD PROCESS */ if (pid == 0) { printf("=== Child Process === "); printf("Child: PID = %d, PPID = %d ", getpid(), getppid()); printf("Child: fork() returned %d (always 0 for child) ", pid); /* Modify all variables */ global_counter = 999; stack_var = 888; *heap_var = 777; strcpy(shared_buffer, "Modified by child"); printf("Child: After modifications: "); printf(" global_counter = %d (same addr: %p) ", global_counter, (void*)&global_counter); printf(" stack_var = %d ", stack_var); printf(" *heap_var = %d ", *heap_var); printf(" buffer = '%s' ", shared_buffer); /* Demonstrate heap_var still points to same virtual address but it's a DIFFERENT physical page (copy-on-write) */ printf(" heap_var pointer = %p (same address, different page!) ", (void*)heap_var); free(heap_var); printf("Child: Exiting with status 42 "); exit(42); /* Child exits with distinctive code */ } /* PARENT PROCESS */ printf("=== Parent Process === "); printf("Parent: PID = %d, fork() returned child PID = %d ", getpid(), pid); /* Wait for child to complete */ int status; pid_t waited = waitpid(pid, &status, 0); if (WIFEXITED(status)) { printf("Parent: Child %d exited with status %d ", waited, WEXITSTATUS(status)); } /* Verify parent's variables are unchanged */ printf("Parent: After child exited: "); printf(" global_counter = %d (unchanged from 0!) ", global_counter); printf(" stack_var = %d (unchanged from 100!) ", stack_var); printf(" *heap_var = %d (unchanged from 200!) ", *heap_var); printf(" buffer = '%s' (unchanged!) ", shared_buffer); /* Key insight: same virtual addresses, completely independent data */ printf(" KEY INSIGHT: Same addresses, independent data. "); printf("Virtual memory makes each process believe it owns all memory. "); free(heap_var); return 0; }62:{"json":{"id":"seed_4783eccf47cedcc30a2705070153bbe5","slug":"fork-system-call","category":"Operating Systems","topic":"fork() System Call","title":"The fork() System Call","description":"Master the fork() system call - the cornerstone of Unix process creation. Explore fork semantics, return value conventions, copy-on-write optimization, parent-child execution dynamics, and protection mechanisms against fork bombs. Understand how this elegant primitive enables all process creation in Unix-like systems.","difficulty":"INTERMEDIATE","estimatedMinutes":60,"pages":[{"id":"seed_106e78f6772907031048bbb916c6cc21","title":"fork() Semantics","order":0,"content":[{"id":"opening-context","title":"The Fundamental Process Creation Primitive","content":[{"data":{"content":"In the Unix philosophy, there exists a single, elegant mechanism for creating new processes: the **fork() system call**. Unlike operating systems that provide multiple process creation primitives with varying semantics, Unix chose a beautifully simple model—every process (except the first) is created by duplicating an existing process.\n\nThis design decision, dating back to the original Unix implementation at Bell Labs in the early 1970s, has profound implications for how we understand process management, resource inheritance, and the entire process lifecycle. The fork() system call is not merely a function to call—it represents a fundamental architectural choice that shapes how Unix-like systems operate."},"type":"text"},{"data":{"icon":"Target","title":"What You Will Learn","content":"This page provides a comprehensive exploration of fork() semantics. You will understand the formal POSIX specification, the conceptual model of process duplication, what exactly gets copied and what gets shared, the atomicity guarantees, and how fork() interacts with the broader operating system. By the end, you will have mastered the theoretical foundations that underpin all Unix process creation.","variant":"info"},"type":"callout"}]},{"id":"concept-process-duplication","title":"The Concept of Process Duplication","content":[{"data":{"content":"At its core, fork() creates a **clone** of the calling process. The calling process becomes the **parent**, and the newly created process becomes the **child**. After fork() completes successfully, there are two processes where previously there was one—both executing the same program, at the same point in the code, with nearly identical memory contents.\n\n**The fundamental principle:**\n\nWhen a process calls fork(), the operating system creates a new process that is an exact duplicate of the calling process at the moment of the call. This duplication includes:\n\n- The entire virtual address space (code, data, heap, stack)\n- All open file descriptors\n- Signal handlers and pending signals\n- Current working directory\n- User and group IDs\n- Environment variables\n- Resource limits\n- The program counter (instruction pointer)"},"type":"text"},{"data":{"icon":"Lightbulb","title":"The Cloning Mental Model","content":"Imagine pressing 'duplicate' on a running program. The clone starts running at exactly the same point, with the same data in memory, the same files open, the same everything. The only difference is that one is designated the 'parent' and one the 'child'—and they can now diverge in their execution paths.","variant":"tip"},"type":"callout"},{"data":{"content":"**Why duplication instead of creation?**\n\nThis design might seem redundant—why create a copy when you likely want a different program? The answer lies in Unix's separation of concerns:\n\n1. **fork()** handles process creation and resource inheritance\n2. **exec()** handles loading a new program image\n\nBy separating these concerns, Unix provides tremendous flexibility. The child process can modify its environment (change file descriptors, adjust privileges, set up pipes) before calling exec() to become a new program. This separation enables patterns like shell pipelines, I/O redirection, and privilege dropping that would be cumbersome with a monolithic 'create process with these parameters' approach."},"type":"text"},{"data":{"rows":[["Unix fork/exec","Duplicate, modify, replace","Maximum flexibility","Two system calls"],["Windows CreateProcess","Single call with parameters","Limited by parameters","One complex call"],["VMS CREATE_PROCESS","Specify everything upfront","Fixed options","One call, many options"]],"caption":"Unix vs Monolithic Process Creation","headers":["Approach","Mechanism","Flexibility","Complexity"]},"type":"table"}],"titleType":"number","titleNumber":1},{"id":"posix-specification","title":"The POSIX Specification","content":[{"data":{"content":"The fork() system call is standardized by POSIX (Portable Operating System Interface), ensuring consistent behavior across Unix-like systems. Understanding the formal specification is essential for writing portable, correct code.\n\n**Function Signature:**"},"type":"text"},{"data":{"code":"#include \n\npid_t fork(void);\n\n/*\n * DESCRIPTION:\n * The fork() function creates a new process. The new process (child process)\n * shall be an exact copy of the calling process (parent process) except for\n * the following differences:\n *\n * - The child has a unique process ID (PID)\n * - The child has a different parent process ID (the PID of the parent)\n * - The child's tms_utime, tms_stime, tms_cutime, and tms_cstime are set to 0\n * - Resource utilizations are set to 0\n * - The child's pending signals are empty\n * - The child does not inherit process memory locks\n * - The child does not inherit timers\n *\n * RETURN VALUE:\n * Upon successful completion, fork() returns 0 to the child process\n * and returns the process ID of the child process to the parent process.\n * Both processes continue to execute from the point of the fork() call.\n * \n * Upon failure, fork() returns -1 to the parent process, no child is created,\n * and errno is set to indicate the error.\n */","fileName":"fork_signature.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Critical POSIX Guarantees:**\n\nThe POSIX specification provides several important guarantees that programmers can rely upon:"},"type":"text"},{"data":{"items":["**Atomicity**: The fork() operation is atomic from the perspective of the calling process. Either the child is fully created, or it is not created at all.","**Distinct PIDs**: Parent and child always have different process IDs. The child's PID is guaranteed to be unique in the system at the time of creation.","**Execution Order Undefined**: POSIX makes no guarantee about which process (parent or child) runs first after fork(). This is implementation-defined and may vary.","**Separate Address Spaces**: The child receives a copy of the parent's address space. Modifications in one do not affect the other (after the fork completes).","**File Descriptor Sharing**: File descriptors are duplicated, but they share the same underlying file table entries. File position is shared between parent and child.","**Signal State**: The child does not inherit pending signals, but signal handlers remain unchanged."],"title":{"icon":"CheckCircle","text":"POSIX fork() Guarantees","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"icon":"AlertCircle","title":"The Scheduler's Choice","content":"Never write code that assumes the parent or child runs first. The scheduler is free to run either process first, and this behavior may change between runs, kernel versions, or system load conditions. Relying on execution order is a recipe for race conditions and Heisenbugs.","variant":"warning"},"type":"callout"}],"titleType":"number","titleNumber":2},{"id":"what-gets-duplicated","title":"What Gets Duplicated","content":[{"data":{"content":"Understanding precisely what fork() duplicates is essential for writing correct concurrent programs. The duplication is comprehensive, but there are important nuances and exceptions.\n\n**Address Space Duplication:**\n\nThe child receives a copy of the parent's entire virtual address space at the moment of fork(). This includes:"},"type":"text"},{"data":{"rows":[["Text (Code)","Executable instructions","Typically shared read-only via COW"],["Data","Initialized global/static variables","Copied, modifications are independent"],["BSS","Uninitialized global/static variables","Copied, modifications are independent"],["Heap","dynamically allocated memory (malloc)","Copied, but pointers still point to same addresses"],["Stack","Local variables, return addresses","Copied, each process has own stack"],["Memory Mappings","mmap'd files, shared memory","Mappings copied, shared mappings remain shared"]],"caption":"Memory Segments Duplicated by fork()","headers":["Segment","Contents","Notes"]},"type":"table"},{"data":{"content":"**File Descriptor Duplication:**\n\nFile descriptors represent one of the most important aspects of fork() semantics. Each open file descriptor in the parent is duplicated in the child:"},"type":"text"},{"data":{"code":"$6a","fileName":"fd_sharing.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"Shared File Offsets","content":"This sharing is intentional and enables shell pipelines to work correctly. However, it means that parent and child reading from the same file descriptor will see interleaved data unless they coordinate. For independent access, open files after fork() or use O_CLOEXEC and re-open.","variant":"warning"},"type":"callout"},{"data":{"content":"**Other Duplicated Resources:**"},"type":"text"},{"data":{"items":["**Signal Handlers**: Signal dispositions (handlers vs SIG_DFL vs SIG_IGN) are preserved","**Signal Mask**: The blocked signal set is inherited","**Current Working Directory**: Both processes share the same cwd initially","**Root Directory**: Used for chroot environments","**Resource Limits**: ulimit values (rlimit) are copied","**Environment Variables**: environ array is copied","**umask**: File creation mask is inherited","**Controlling Terminal**: Both processes share the same controlling terminal","**Process Group ID**: Child is in the same process group as parent (initially)","**Session ID**: Child is in the same session as parent"],"title":{"icon":"BookOpen","text":"Resources Inherited by Child","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"}],"titleType":"number","titleNumber":3},{"id":"what-not-inherited","title":"What Is NOT Inherited","content":[{"data":{"content":"Equally important is understanding what the child process does **not** inherit from the parent. These distinctions exist for security, correctness, and isolation reasons."},"type":"text"},{"data":{"items":["**Process ID (PID)**: The child receives a unique PID, distinct from the parent","**Parent Process ID (PPID)**: The child's PPID is set to the parent's PID","**Pending Signals**: The child starts with no pending signals (even if parent has undelivered signals)","**Process Resource Utilizations**: CPU time, page faults, etc. start at zero","**Memory Locks**: mlock() regions are not inherited (security concern)","**File Locks (flock/fcntl)**: Advisory and mandatory locks are not inherited","**Pending Timers**: timer_create() timers are not inherited","**Pending Async I/O Operations**: aio operations are not inherited","**Process Tracing State**: Child is not traced even if parent is","**Thread ID (in multi-threaded programs)**: Only calling thread exists in child"],"title":{"icon":"XCircle","text":"Not Inherited by Child Process","type":"icon","color":"destructive","variant":"outline-circle"},"variant":"glass"},"type":"list"},{"data":{"icon":"Info","title":"File Locks Are Not Inherited","content":"This may seem surprising given that file descriptors are shared, but locks are associated with processes, not file descriptors. If child inherited locks, coordinating lock release would be nearly impossible. The child must acquire its own locks if needed.","variant":"note"},"type":"callout"},{"data":{"content":"**The Single-Thread Guarantee:**\n\nOne particularly important rule: in a multi-threaded program, only the thread that calls fork() exists in the child process. All other threads simply vanish. This has profound implications:"},"type":"text"},{"data":{"code":"$6b","fileName":"fork_threads.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"AlertCircle","title":"fork() and Threads Don't Mix Well","content":"This is one of the most subtle and dangerous aspects of Unix programming. If you must fork() from a multi-threaded program, either do so early (before creating threads), or immediately call exec() after fork() to replace the confused state with a fresh program image.","variant":"error"},"type":"callout"}],"titleType":"number","titleNumber":4},{"id":"the-fork-point","title":"The Fork Point","content":[{"data":{"content":"One of the most conceptually important aspects of fork() is understanding exactly where execution resumes in both processes. This is often confusing for newcomers but becomes intuitive with practice.\n\n**The Central Insight:**\n\nWhen fork() returns, **both** processes resume execution at exactly the same point—the instruction immediately after the fork() call. It's as if a single stream of execution splits into two parallel streams."},"type":"text"},{"data":{"code":"$6c","fileName":"fork_point_visualization.c","showLineNumbers":true},"type":"code"},{"data":{"content":"**Conceptualizing fork() Semantically:**\n\nThink of fork() as creating a **snapshot** of the process at a precise moment in time. The snapshot includes:\n\n- The program counter (where to continue executing)\n- All register values\n- The entire memory state\n- All kernel resources associated with the process\n\nThe child process **starts** from this snapshot, as if it had always been running and just happened to 'wake up' from the fork() call. There's no separate 'child main()' or starting point—the child simply continues where the parent was."},"type":"text"},{"data":{"items":["**Cloning Machine**: A machine creates an exact duplicate of a running entity; both continue from that moment","**Timeline Split**: History splits into two parallel timelines from the fork point","**Process Mitosis**: Like cell division—one becomes two, each carrying complete genetic information","**Save Point**: Imagine saving a game, then loading the save in two separate instances—both start from that exact point"],"title":"Mental Models for fork()","variant":"accent"},"type":"list"},{"data":{"icon":"Lightbulb","title":"The fork() Paradox","content":"Here's the philosophical puzzle: fork() is called once but returns twice. This seems impossible until you realize that by the time it returns, there are two callers—each receiving their own return value. It's not magic; it's just that the caller was duplicated before the return.","variant":"tip"},"type":"callout"}],"titleType":"number","titleNumber":5},{"id":"ancestry-model","title":"The Ancestry Model","content":[{"data":{"content":"Every process in a Unix system (except the first process, typically called **init** or **systemd**) has a parent. This creates a tree structure of processes, with a single root.\n\n**The Process Family Tree:**"},"type":"text"},{"data":{"code":"# Typical Linux process tree (simplified)\n\ninit/systemd (PID 1)\n├── login\n│ └── bash\n│ ├── vim\n│ └── firefox\n│ ├── firefox (content)\n│ ├── firefox (content)\n│ └── firefox (content)\n├── sshd\n│ └── sshd (session)\n│ └── bash\n│ └── python script.py\n│ └── worker subprocess\n├── cron\n│ └── backup.sh\n└── docker\n └── containerd\n └── container process\n\n# View with: pstree or ps auxf\n# Key insight: Every process has exactly one parent (except PID 1)","fileName":"process_tree.txt","showLineNumbers":true},"type":"code"},{"data":{"content":"**Key Process Relationships:**"},"type":"text"},{"data":{"rows":[["PID","Process ID - unique identifier for this process","getpid()"],["PPID","Parent Process ID - PID of the process that created this one via fork()","getppid()"],["PGID","Process Group ID - for job control, all processes in a pipeline share PGID","getpgrp(), setpgid()"],["SID","Session ID - for terminal/session management","getsid(), setsid()"],["Child","A process created by fork() from this process","(no direct access, track via wait())"],["Sibling","Another process with the same parent","(no direct access)"]],"caption":"Process Relationship Terminology","headers":["Term","Definition","System Call to Access"]},"type":"table"},{"data":{"content":"**The init Process:**\n\nPID 1 is special in Unix systems:\n\n- It's the ancestor of all other processes\n- It cannot be killed (the kernel protects it)\n- It 'adopts' orphaned processes (when a parent dies, children's PPID becomes 1)\n- It's responsible for reaping zombie processes of adopted children\n\nThis hierarchical model enables powerful features like job control (Ctrl+Z, bg, fg), signal cascading (kill a parent, children can be notified), and resource accounting (track all descendants of a process)."},"type":"text"},{"data":{"icon":"Info","title":"Modern init Systems","content":"On modern Linux systems, systemd has replaced traditional init as PID 1. However, the fundamental ancestry model remains unchanged—systemd still serves as the root of the process tree and adopts orphaned processes.","variant":"note"},"type":"callout"}],"titleType":"number","titleNumber":6},{"id":"fork-semantics-code","title":"fork() Semantics in Code","content":[{"data":{"content":"Let's solidify our understanding with a comprehensive example that demonstrates all the key semantic points of fork():"},"type":"text"},{"data":{"code":"$6d","fileName":"complete_fork_example.c","showLineNumbers":true},"type":"code"},{"data":{"icon":"CheckCircle","title":"Expected Output","content":"Running this program demonstrates that parent and child have completely independent memory, despite having the same virtual addresses. The child's modifications never affect the parent's data. This isolation is the foundation of process-based security and stability.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":7},{"id":"summary","title":"Summary: fork() Semantics","content":[{"data":{"content":"We have thoroughly explored the semantics of the fork() system call. Let's consolidate the key concepts:"},"type":"text"},{"data":{"type":"ordered","items":["**fork() creates an exact duplicate** of the calling process at the moment of the call","**The address space is copied** including text, data, heap, and stack segments","**File descriptors are duplicated** but share file table entries (shared offset)","**Parent and child have different PIDs** and the child's PPID is set to parent's PID","**Execution order is undefined** by POSIX—never assume which runs first","**Certain resources are NOT inherited**: pending signals, locks, timers, CPU time accounting","**fork() in multi-threaded programs** copies only the calling thread—extreme caution required","**Process ancestry forms a tree** with init/systemd (PID 1) at the root"],"title":{"icon":"CheckCircle","text":"Key Takeaways","type":"icon","color":"primary","variant":"outline-circle"},"variant":"accent"},"type":"list"},{"data":{"content":"**What's Next:**\n\nNow that we understand what fork() does semantically, we'll explore how to interpret its return values in the next page. The ability to distinguish between parent and child execution is the key to using fork() effectively in practice."},"type":"text"},{"data":{"icon":"CheckCircle","title":"Page Complete","content":"You now have a comprehensive understanding of fork() semantics. You understand what gets duplicated, what doesn't, the process ancestry model, and the conceptual foundation of Unix process creation. Next, we'll examine the return value conventions that enable branching parent and child execution paths.","variant":"success"},"type":"callout"}],"titleType":"number","titleNumber":8}],"isLocked":false},{"id":"seed_0fb95669d6fb8c5a26517075f24a10c7","title":"Return Values","order":1,"content":null,"isLocked":true},{"id":"seed_bedabd7b781fd78d6eacee2fcf84ab92","title":"Copy-on-Write","order":2,"content":null,"isLocked":true},{"id":"seed_49166e44df252cb3e1c2c11ea35079c9","title":"Parent vs Child Execution","order":3,"content":null,"isLocked":true},{"id":"seed_710d3f0bf4dc69cf28534e444b0052a7","title":"Fork Bombs and Prevention","order":4,"content":null,"isLocked":true}]}}