Operating Systemsfork() System Call

The fork() System Call

LevelIntermediate

Duration60 mins

Topicfork() System Call

1 / 5

fork() Semantics

The Fundamental Process Creation Primitive

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.

This 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.

What You Will Learn

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.

The Concept of Process Duplication

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.

The fundamental principle:

When 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:

The entire virtual address space (code, data, heap, stack)
All open file descriptors
Signal handlers and pending signals
Current working directory
User and group IDs
Environment variables
Resource limits
The program counter (instruction pointer)

The Cloning Mental Model

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.

Why duplication instead of creation?

This design might seem redundant—why create a copy when you likely want a different program? The answer lies in Unix's separation of concerns:

fork() handles process creation and resource inheritance
exec() handles loading a new program image

By 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.

Unix vs Monolithic Process Creation
Approach	Mechanism	Flexibility	Complexity
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

The POSIX Specification

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.

Function Signature:

fork_signature.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <unistd.h>
 
pid_t fork(void);
 
/*
 * DESCRIPTION:
 *   The fork() function creates a new process. The new process (child process)
 *   shall be an exact copy of the calling process (parent process) except for
 *   the following differences:
 *
 *   - The child has a unique process ID (PID)
 *   - The child has a different parent process ID (the PID of the parent)
 *   - The child's tms_utime, tms_stime, tms_cutime, and tms_cstime are set to 0
 *   - Resource utilizations are set to 0
 *   - The child's pending signals are empty
 *   - The child does not inherit process memory locks
 *   - The child does not inherit timers
 *
 * RETURN VALUE:
 *   Upon successful completion, fork() returns 0 to the child process
 *   and returns the process ID of the child process to the parent process.
 *   Both processes continue to execute from the point of the fork() call.
 *   
 *   Upon failure, fork() returns -1 to the parent process, no child is created,
 *   and errno is set to indicate the error.
 */

Critical POSIX Guarantees:

The POSIX specification provides several important guarantees that programmers can rely upon:

POSIX fork() Guarantees

•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.

The Scheduler's Choice

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.

What Gets Duplicated

Understanding precisely what fork() duplicates is essential for writing correct concurrent programs. The duplication is comprehensive, but there are important nuances and exceptions.

Address Space Duplication:

The child receives a copy of the parent's entire virtual address space at the moment of fork(). This includes:

Memory Segments Duplicated by fork()
Segment	Contents	Notes
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

File Descriptor Duplication:

File descriptors represent one of the most important aspects of fork() semantics. Each open file descriptor in the parent is duplicated in the child:

fd_sharing.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/*
 * 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 <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>
 
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\n", lseek(fd, 0, SEEK_CUR));
        _exit(0);
    } else {
        wait(NULL);  // Wait for child
        // Parent: offset has moved!
        printf("Parent offset: %ld\n", lseek(fd, 0, SEEK_CUR));
        // If child read 10 bytes, parent's offset is also at 10!
    }
    
    close(fd);
    return 0;
}

Shared File Offsets

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.

Other Duplicated Resources:

Resources Inherited by Child

•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

What Is NOT Inherited

Equally important is understanding what the child process does not inherit from the parent. These distinctions exist for security, correctness, and isolation reasons.

Not Inherited by Child Process

•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

File Locks Are Not Inherited

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.

The Single-Thread Guarantee:

One 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:

fork_threads.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
/*
 * 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 <pthread.h>
#include <unistd.h>
#include <stdio.h>
 
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
void* thread_func(void* arg) {
    pthread_mutex_lock(&lock);
    printf("Thread A: Holding lock forever...\n");
    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...\n");
        pthread_mutex_lock(&lock);  // DEADLOCK!
        printf("Child: Got lock!\n");  // 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()
 */

fork() and Threads Don't Mix Well

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.

The Fork Point

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.

The Central Insight:

When 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.

fork_point_visualization.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/*
 * 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 <stdio.h>
#include <unistd.h>
#include <sys/types.h>
 
int main() {
    printf("Before fork: pid = %d\n", 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\n", 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\n", 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
 */

Conceptualizing fork() Semantically:

Think of fork() as creating a snapshot of the process at a precise moment in time. The snapshot includes:

The program counter (where to continue executing)
All register values
The entire memory state
All kernel resources associated with the process

The 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.

Mental Models for fork()

•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

The fork() Paradox

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.

The Ancestry Model

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.

The Process Family Tree:

process_tree.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Typical Linux process tree (simplified)
 
init/systemd (PID 1)
├── login
│   └── bash
│       ├── vim
│       └── firefox
│           ├── firefox (content)
│           ├── firefox (content)
│           └── firefox (content)
├── sshd
│   └── sshd (session)
│       └── bash
│           └── python script.py
│               └── worker subprocess
├── cron
│   └── backup.sh
└── docker
    └── containerd
        └── container process
 
# View with: pstree or ps auxf
# Key insight: Every process has exactly one parent (except PID 1)

Key Process Relationships:

Process Relationship Terminology
Term	Definition	System Call to Access
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)

The init Process:

PID 1 is special in Unix systems:

It's the ancestor of all other processes
It cannot be killed (the kernel protects it)
It 'adopts' orphaned processes (when a parent dies, children's PPID becomes 1)
It's responsible for reaping zombie processes of adopted children

This 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).

Modern init Systems

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.

fork() Semantics in Code

Let's solidify our understanding with a comprehensive example that demonstrates all the key semantic points of fork():

complete_fork_example.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
/*
 * Complete fork() Semantics Demonstration
 * Compile: gcc -o fork_demo fork_demo.c
 * Run: ./fork_demo
 */
 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <string.h>
 
/* 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() ===\n");
    printf("PID: %d, PPID: %d\n", getpid(), getppid());
    printf("global_counter addr: %p, value: %d\n", 
           (void*)&global_counter, global_counter);
    printf("stack_var addr: %p, value: %d\n", 
           (void*)&stack_var, stack_var);
    printf("heap_var addr: %p, value: %d (arr at %p)\n", 
           (void*)heap_var, *heap_var, (void*)&heap_var);
    printf("\n");
    
    /* === 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 ===\n");
        printf("Child: PID = %d, PPID = %d\n", getpid(), getppid());
        printf("Child: fork() returned %d (always 0 for child)\n", pid);
        
        /* Modify all variables */
        global_counter = 999;
        stack_var = 888;
        *heap_var = 777;
        strcpy(shared_buffer, "Modified by child");
        
        printf("Child: After modifications:\n");
        printf("  global_counter = %d (same addr: %p)\n", 
               global_counter, (void*)&global_counter);
        printf("  stack_var = %d\n", stack_var);
        printf("  *heap_var = %d\n", *heap_var);
        printf("  buffer = '%s'\n", 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!)\n", 
               (void*)heap_var);
        
        free(heap_var);
        printf("Child: Exiting with status 42\n");
        exit(42);  /* Child exits with distinctive code */
    }
    
    /* PARENT PROCESS */
    printf("=== Parent Process ===\n");
    printf("Parent: PID = %d, fork() returned child PID = %d\n", 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\n", 
               waited, WEXITSTATUS(status));
    }
    
    /* Verify parent's variables are unchanged */
    printf("Parent: After child exited:\n");
    printf("  global_counter = %d (unchanged from 0!)\n", global_counter);
    printf("  stack_var = %d (unchanged from 100!)\n", stack_var);
    printf("  *heap_var = %d (unchanged from 200!)\n", *heap_var);
    printf("  buffer = '%s' (unchanged!)\n", shared_buffer);
    
    /* Key insight: same virtual addresses, completely independent data */
    printf("\nKEY INSIGHT: Same addresses, independent data.\n");
    printf("Virtual memory makes each process believe it owns all memory.\n");
    
    free(heap_var);
    return 0;
}

Expected Output

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.

Summary: fork() Semantics

We have thoroughly explored the semantics of the fork() system call. Let's consolidate the key concepts:

Key Takeaways

•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

What's Next:

Now 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.

Page Complete

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.

1 / 5

Loading learning content...

Operating Systemsfork() System Call

The fork() System Call

LevelIntermediate

Duration60 mins

Topicfork() System Call

1 / 5

fork() Semantics

The Fundamental Process Creation Primitive

What You Will Learn

The Concept of Process Duplication

The fundamental principle:

When 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:

The entire virtual address space (code, data, heap, stack)
All open file descriptors
Signal handlers and pending signals
Current working directory
User and group IDs
Environment variables
Resource limits
The program counter (instruction pointer)

The Cloning Mental Model

Why duplication instead of creation?

This design might seem redundant—why create a copy when you likely want a different program? The answer lies in Unix's separation of concerns:

fork() handles process creation and resource inheritance
exec() handles loading a new program image

Unix vs Monolithic Process Creation
Approach	Mechanism	Flexibility	Complexity
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

The POSIX Specification

Function Signature:

fork_signature.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
#include <unistd.h>
 
pid_t fork(void);
 
/*
 * DESCRIPTION:
 *   The fork() function creates a new process. The new process (child process)
 *   shall be an exact copy of the calling process (parent process) except for
 *   the following differences:
 *
 *   - The child has a unique process ID (PID)
 *   - The child has a different parent process ID (the PID of the parent)
 *   - The child's tms_utime, tms_stime, tms_cutime, and tms_cstime are set to 0
 *   - Resource utilizations are set to 0
 *   - The child's pending signals are empty
 *   - The child does not inherit process memory locks
 *   - The child does not inherit timers
 *
 * RETURN VALUE:
 *   Upon successful completion, fork() returns 0 to the child process
 *   and returns the process ID of the child process to the parent process.
 *   Both processes continue to execute from the point of the fork() call.
 *   
 *   Upon failure, fork() returns -1 to the parent process, no child is created,
 *   and errno is set to indicate the error.
 */

Critical POSIX Guarantees:

The POSIX specification provides several important guarantees that programmers can rely upon:

POSIX fork() Guarantees

•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.

The Scheduler's Choice

What Gets Duplicated

Understanding precisely what fork() duplicates is essential for writing correct concurrent programs. The duplication is comprehensive, but there are important nuances and exceptions.

Address Space Duplication:

The child receives a copy of the parent's entire virtual address space at the moment of fork(). This includes:

Memory Segments Duplicated by fork()
Segment	Contents	Notes
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

File Descriptor Duplication:

File descriptors represent one of the most important aspects of fork() semantics. Each open file descriptor in the parent is duplicated in the child:

fd_sharing.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/*
 * 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 <stdio.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>
 
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\n", lseek(fd, 0, SEEK_CUR));
        _exit(0);
    } else {
        wait(NULL);  // Wait for child
        // Parent: offset has moved!
        printf("Parent offset: %ld\n", lseek(fd, 0, SEEK_CUR));
        // If child read 10 bytes, parent's offset is also at 10!
    }
    
    close(fd);
    return 0;
}

Shared File Offsets

Other Duplicated Resources:

Resources Inherited by Child

•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

What Is NOT Inherited

Equally important is understanding what the child process does not inherit from the parent. These distinctions exist for security, correctness, and isolation reasons.

Not Inherited by Child Process

•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

File Locks Are Not Inherited

The Single-Thread Guarantee:

One 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:

fork_threads.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
/*
 * 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 <pthread.h>
#include <unistd.h>
#include <stdio.h>
 
pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;
 
void* thread_func(void* arg) {
    pthread_mutex_lock(&lock);
    printf("Thread A: Holding lock forever...\n");
    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...\n");
        pthread_mutex_lock(&lock);  // DEADLOCK!
        printf("Child: Got lock!\n");  // 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()
 */

fork() and Threads Don't Mix Well

The Fork Point

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.

The Central Insight:

fork_point_visualization.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
/*
 * 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 <stdio.h>
#include <unistd.h>
#include <sys/types.h>
 
int main() {
    printf("Before fork: pid = %d\n", 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\n", 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\n", 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
 */

Conceptualizing fork() Semantically:

Think of fork() as creating a snapshot of the process at a precise moment in time. The snapshot includes:

The program counter (where to continue executing)
All register values
The entire memory state
All kernel resources associated with the process

Mental Models for fork()

•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

The fork() Paradox

The Ancestry Model

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.

The Process Family Tree:

process_tree.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# Typical Linux process tree (simplified)
 
init/systemd (PID 1)
├── login
│   └── bash
│       ├── vim
│       └── firefox
│           ├── firefox (content)
│           ├── firefox (content)
│           └── firefox (content)
├── sshd
│   └── sshd (session)
│       └── bash
│           └── python script.py
│               └── worker subprocess
├── cron
│   └── backup.sh
└── docker
    └── containerd
        └── container process
 
# View with: pstree or ps auxf
# Key insight: Every process has exactly one parent (except PID 1)

Key Process Relationships:

Process Relationship Terminology
Term	Definition	System Call to Access
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)

The init Process:

PID 1 is special in Unix systems:

It's the ancestor of all other processes
It cannot be killed (the kernel protects it)
It 'adopts' orphaned processes (when a parent dies, children's PPID becomes 1)
It's responsible for reaping zombie processes of adopted children

Modern init Systems

fork() Semantics in Code

Let's solidify our understanding with a comprehensive example that demonstrates all the key semantic points of fork():

complete_fork_example.c
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
/*
 * Complete fork() Semantics Demonstration
 * Compile: gcc -o fork_demo fork_demo.c
 * Run: ./fork_demo
 */
 
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <string.h>
 
/* 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() ===\n");
    printf("PID: %d, PPID: %d\n", getpid(), getppid());
    printf("global_counter addr: %p, value: %d\n", 
           (void*)&global_counter, global_counter);
    printf("stack_var addr: %p, value: %d\n", 
           (void*)&stack_var, stack_var);
    printf("heap_var addr: %p, value: %d (arr at %p)\n", 
           (void*)heap_var, *heap_var, (void*)&heap_var);
    printf("\n");
    
    /* === 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 ===\n");
        printf("Child: PID = %d, PPID = %d\n", getpid(), getppid());
        printf("Child: fork() returned %d (always 0 for child)\n", pid);
        
        /* Modify all variables */
        global_counter = 999;
        stack_var = 888;
        *heap_var = 777;
        strcpy(shared_buffer, "Modified by child");
        
        printf("Child: After modifications:\n");
        printf("  global_counter = %d (same addr: %p)\n", 
               global_counter, (void*)&global_counter);
        printf("  stack_var = %d\n", stack_var);
        printf("  *heap_var = %d\n", *heap_var);
        printf("  buffer = '%s'\n", 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!)\n", 
               (void*)heap_var);
        
        free(heap_var);
        printf("Child: Exiting with status 42\n");
        exit(42);  /* Child exits with distinctive code */
    }
    
    /* PARENT PROCESS */
    printf("=== Parent Process ===\n");
    printf("Parent: PID = %d, fork() returned child PID = %d\n", 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\n", 
               waited, WEXITSTATUS(status));
    }
    
    /* Verify parent's variables are unchanged */
    printf("Parent: After child exited:\n");
    printf("  global_counter = %d (unchanged from 0!)\n", global_counter);
    printf("  stack_var = %d (unchanged from 100!)\n", stack_var);
    printf("  *heap_var = %d (unchanged from 200!)\n", *heap_var);
    printf("  buffer = '%s' (unchanged!)\n", shared_buffer);
    
    /* Key insight: same virtual addresses, completely independent data */
    printf("\nKEY INSIGHT: Same addresses, independent data.\n");
    printf("Virtual memory makes each process believe it owns all memory.\n");
    
    free(heap_var);
    return 0;
}

Expected Output

Summary: fork() Semantics

We have thoroughly explored the semantics of the fork() system call. Let's consolidate the key concepts:

Key Takeaways

•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

What's Next:

Page Complete

1 / 5