Process Creation

When an operating system creates a child process, one of the most consequential design decisions is how resources are shared between parent and child. This choice sits at the intersection of performance, isolation, security, and programming model—and different operating systems make fundamentally different tradeoffs.

At one extreme lies complete sharing: parent and child access the same memory, file descriptors, and identity. At the other extreme lies complete isolation: child receives entirely independent copies of everything. Most practical systems occupy a nuanced middle ground, sharing some resources while copying or isolating others.

Understanding these options is essential for writing correct concurrent programs, optimizing performance, debugging memory corruption, and designing secure systems.

Operating systems offer three fundamental approaches to resource sharing between parent and child processes:

Model 1: Share Everything

Parent and child access the same resources. Changes made by one are immediately visible to the other.

Characteristics:

• Minimal creation overhead (no copying)
• Shared state enables easy communication
• Shared state creates synchronization challenges
• One process can corrupt another's data

Example: Threads share the same address space and file descriptor table.

Model 2: Copy Everything

Child receives an independent copy of all resources. Parent and child are completely isolated after creation.

Characteristics:

• Maximum isolation and safety
• Higher creation overhead (copying takes time)
• Changes in one process invisible to other
• Acts as snapshot of parent state at fork time

Example: Traditional fork() semantics—child gets copy of memory.

Model 3: Selective Sharing

Some resources are shared, others are copied. Provides fine-grained control over isolation boundaries.

Characteristics:

• Flexible—choose per-resource
• Complexity in understanding what's shared
• Enables optimizations (share read-only code, copy mutable state)
• Foundation for modern containers and sandboxing

Example: clone() with specific flags controls sharing.

Memory is the most significant resource to consider when creating processes. The choice between sharing and copying has profound implications for performance, correctness, and isolation.

The Copy-on-Write Optimization

Naively copying all memory at fork() time would be prohibitively expensive—a process with 1GB of memory would require copying 1GB of data. Modern operating systems use Copy-on-Write (COW) to defer this cost.

How Copy-on-Write Works:

1. At fork(): Parent and child share the same physical memory pages
2. Page Table Setup: Both processes' page tables point to the same physical frames
3. Mark Read-Only: All shared pages are marked read-only in both processes
4. Trap on Write: When either process tries to write, a page fault occurs
5. Copy and Remap: Kernel copies the page, gives the writer its own copy, marks it writable
6. Continue Execution: Only the actually-modified pages get copied

Performance Implications

Cache-Efficient Fork:

• fork() itself is very fast—mostly page table manipulation
• No actual memory copying until writes occur
• Many forked processes exec() immediately, never modifying memory
• Pages that are never written are never copied

When COW Isn't Enough:

• Memory-intensive children that modify most of their memory eventually copy everything anyway
• COW page faults add latency to first writes
• Kernel memory for tracking COW pages adds overhead
• Very large processes may experience significant copy costs even with COW

Memory Regions and Sharing Semantics

Different memory regions have different sharing behaviors:

File descriptors present a unique sharing scenario: the descriptor table is copied, but the underlying file table entries are shared. This creates both opportunities and hazards.

The Three-Level File System Abstraction

To understand file descriptor sharing, you must understand the three levels of abstraction:

1. File Descriptor Table (per-process)

   • Array of file descriptor entries
   • Index = fd number (0, 1, 2, ...)
   • Each entry points to a file table entry
   • Copied at fork() (with flags_inherit behavior)

2. File Table (system-wide)

   • Kernel maintains one table for all open files
   • Entries contain: file offset, mode (read/write), reference count
   • Shared between parent and child after fork
   • Entry deleted when reference count reaches 0

3. Inode Table (system-wide)

   • One entry per actual file on disk
   • Contains file metadata, data block pointers
   • Referenced by file table entries

Implications of Shared File Table Entries

Shared File Offset:

The most important consequence: parent and child share the file offset.

int fd = open("data.txt", O_RDWR);
lseek(fd, 0, SEEK_SET);  // Offset = 0

pid_t pid = fork();

if (pid == 0) {
    // Child
    char buf[100];
    read(fd, buf, 100);  // Reads bytes 0-99, advances offset to 100
    _exit(0);
}

wait(NULL);
// Parent's offset is now 100! Child's read advanced it.
char buf[100];
read(fd, buf, 100);  // Reads bytes 100-199

This behavior is intentional—it enables concurrent log writing without explicit coordination:

// Both parent and child can write to log
// Writes are atomic (up to PIPE_BUF for pipes, larger for regular files)
// Shared offset ensures sequential log entries without gaps

Close-on-Exec (FD_CLOEXEC)

Sometimes you DON'T want file descriptors to be inherited by children, especially when exec() is called. The close-on-exec flag causes a file descriptor to be automatically closed when the process exec()s a new program.

// Method 1: Set flag after open
int fd = open("secret.key", O_RDONLY);
fcntl(fd, F_SETFD, FD_CLOEXEC);

// Method 2: Use O_CLOEXEC at open time (preferred, atomic)
int fd = open("secret.key", O_RDONLY | O_CLOEXEC);

// Method 3: Set non-inheritable (same effect)
// After exec(), this FD will not exist in the new program

Security Implication: Sensitive file descriptors (passwords, crypto keys, privileged sockets) should always use close-on-exec to prevent leaking to exec'd programs.

While fork() provides all-or-nothing semantics (copy everything, except what COW optimizes), Linux's clone() system call enables precise control over what is shared and what is copied.

clone() vs fork()

Conceptually:

• fork() = clone() with no sharing flags
• Thread creation = clone() with maximum sharing flags

clone() Flags

The clone() system call accepts flags that individually control each resource:

Thread Creation via clone()

POSIX threads (pthreads) are implemented using clone() with these typical flags:

clone(thread_function,
      child_stack,
      CLONE_VM |           // Share address space
      CLONE_FS |           // Share FS info
      CLONE_FILES |        // Share file descriptors
      CLONE_SIGHAND |      // Share signal handlers
      CLONE_THREAD |       // Same thread group (TGID)
      CLONE_SETTLS |       // Set thread-local storage
      CLONE_PARENT_SETTID | // Write TID to parent memory
      CLONE_CHILD_CLEARTID, // Clear TID on exit (for futex)
      arg);

This creates a new thread that shares almost everything with its creator—the defining characteristic of threads versus processes.

Namespace Flags for Containerization

The CLONE_NEW* flags create new namespaces, which is the foundation of Linux containers:

clone(init_function,
      stack_top,
      CLONE_NEWPID |  // New PID namespace (child sees itself as PID 1)
      CLONE_NEWNS |   // New mount namespace (isolated filesystem view)
      CLONE_NEWNET |  // New network namespace (private network stack)
      CLONE_NEWUTS |  // New UTS namespace (private hostname)
      CLONE_NEWIPC |  // New IPC namespace (private message queues)
      CLONE_NEWUSER | // New user namespace (private UID mappings)
      SIGCHLD,
      NULL);

Docker, Kubernetes, and LXC all use these mechanisms.

Let's examine how different applications and patterns use resource sharing strategically.

Pattern 1: Worker Process Pool

Scenario: Web server wants multiple worker processes to serve requests.

Sharing Strategy:

• Fork workers from master after initialization (share read-only config, code)
• Each worker has independent memory (for request handling)
• Share listening socket FD via inheritance
• Workers compete for connections via accept()

// Master opens socket, then forks
int listen_fd = socket(AF_INET, SOCK_STREAM, 0);
bind(listen_fd, ...);
listen(listen_fd, 128);

for (int i = 0; i < num_workers; i++) {
    if (fork() == 0) {
        // Worker process
        while (1) {
            int conn = accept(listen_fd, ...);  // Inherited FD
            handle_request(conn);
            close(conn);
        }
    }
}

Examples: Apache prefork MPM, Nginx workers, Gunicorn

Pattern 2: Secure Sandbox (Minimal Sharing)

Scenario: Run untrusted code with minimal access to parent's resources.

Sharing Strategy:

• Use namespaces to isolate (CLONE_NEWPID, CLONE_NEWNS, etc.)
• Don't inherit any file descriptors (close all before exec)
• Drop privileges before exec
• Use seccomp to limit system calls

// Highly isolated child
clone(sandbox_function,
      stack_top,
      CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWUSER | SIGCHLD,
      NULL);

// In sandbox_function:
// - Close all FDs
// - Drop capabilities
// - Apply seccomp filter
// - exec untrusted binary

Examples: Chrome sandbox, Firejail, systemd-nspawn

Pattern 3: Parallel Computation (Maximum Sharing)

Scenario: Parallel algorithm with shared data structures.

Sharing Strategy:

• Use threads (CLONE_VM shares memory)
• Coordinate with mutexes/atomics
• Each thread has private stack, TLS

pthread_t threads[NUM_THREADS];

// Shared data
int results[NUM_THREADS];
int shared_counter = 0;
pthread_mutex_t counter_lock = PTHREAD_MUTEX_INITIALIZER;

for (int i = 0; i < NUM_THREADS; i++) {
    pthread_create(&threads[i], NULL, worker, &i);
}

// Workers share address space, can access shared_counter with synchronization

Examples: OpenMP parallel regions, Java parallel streams, Rayon in Rust

Different operating systems offer different resource sharing mechanisms, reflecting different design philosophies.

Windows: CreateProcess and Handle Inheritance

Windows does not have fork()—it uses CreateProcess() which always loads a new executable. Resource sharing is controlled differently:

macOS/BSD: fork() + posix_spawn()

macOS and BSD support fork() but encourage posix_spawn() for new code:

• posix_spawn() atomically creates process and execs new program
• More explicit about what is inherited via file_actions and attrp
• Better performance for fork-then-exec pattern
• Recommended by Apple for new development

#include <spawn.h>

extern char **environ;

posix_spawn_file_actions_t actions;
posix_spawn_file_actions_init(&actions);

// Close fd 3 in child
posix_spawn_file_actions_addclose(&actions, 3);

// Redirect stdin from file
posix_spawn_file_actions_addopen(&actions, 0, "input.txt", O_RDONLY, 0);

pid_t pid;
posix_spawn(&pid, "/bin/ls", &actions, NULL, 
            (char*[]){"ls", "-la", NULL}, environ);

Resource sharing is one of the most consequential decisions in process creation, affecting performance, isolation, security, and programming model. Modern operating systems provide flexible mechanisms to make these tradeoffs explicit.

What's Next:

With resource sharing options understood, the next page examines execution options—the choices a parent has for how it and its child execute after creation: concurrently, sequentially, or in some combined pattern. These decisions affect program structure, responsiveness, and resource utilization.