Why fork() is such a weird API

Other systems take a program and arguments. Unix takes your whole process and clones it. The reasons are half historical accident, half deep insight — and the seams still show.

Why it exists

The first time you actually look at fork(), it should feel wrong. You call one function, and it returns twice — once in the original process, once in a new copy of the original process that magically picks up at the exact same line of code. The two copies share nothing going forward; they’re separate processes with their own memory, but they started life as identical twins mid-instruction.

Every other operating system in wide use models “make a new process” as “give me a program and some arguments, and I’ll start it for you” — Windows has CreateProcess, classic Mac OS / VMS / older mainframes had similar spawn-style calls. Unix said: don’t pass me a program. Pass me yourself. The new program is a separate step (exec).

Why? The honest answer is that fork existed before there was a sensible alternative. The earliest Unix ran on a PDP-7 with no MMU and tiny memory; “swap the current process out, copy it, swap one of the copies back in” was, in 1969, easier than designing a general “start-this-program” syscall with all its options. Dennis Ritchie’s own retrospective (“The Evolution of the Unix Time-sharing System”) describes fork as a quick implementation choice that turned out to be hard to dislodge once the rest of the system grew up around it.

But once it was there, people noticed it had a strange property: it cleanly separates creating a new process from deciding what that process will run. That separation is the deep insight, and it’s why fork outlived the PDP-7.

Why it matters now

Even if you never write fork() by hand, you live downstream of it:

• Every shell pipeline is fork-then-exec, repeated. ls | grep foo | wc is three forks and three execs, with file descriptors wired between them in the gap between fork and exec.
• Servers like nginx, PostgreSQL, and CPython multiprocessing all use fork to cheaply spin up workers that share read-only state with the parent.
• The GIL workaround in Python is fork. When you reach for multiprocessing to use multiple cores, you’re using fork (on Linux/macOS) under the hood.
• Container runtimes are essentially fork-with-extra-flags. Linux’s clone() is the generalized version, and namespaces — the thing that makes a container a container — are arguments to it.
• Fork’s weirdness is also why some things don’t work in AI/ML stacks. PyTorch DataLoader’s fork start method occasionally deadlocks because the child inherits a CUDA context, threadpool, or malloc lock from the parent that’s now in an inconsistent state. The recommended fix is spawn — which is, basically, “stop using fork.”

The short answer

fork = duplicate the current process into two + give each a different return value

The parent gets back the child’s PID; the child gets back zero. Same code, same memory contents, same open files — from that instant on, two independent processes running the same program. What you do after fork (usually exec to replace your program, or just keep running) is the creative part.

How it works

The two-return-values trick

It’s not really two returns. It’s one syscall, two processes. The kernel duplicates the calling process, schedules both, and arranges that when each one resumes from the syscall, the return value register holds something different — 0 in the child, the child’s PID in the parent. So this idiom:

pid_t pid = fork();
if (pid == 0) {
    // child: replace ourselves with a new program
    execvp("ls", argv);
} else if (pid > 0) {
    // parent: wait for child to finish
    waitpid(pid, &status, 0);
} else {
    // fork failed
}

…is one piece of source code that compiles to one binary, but at runtime the if branches differently in each process because the syscall handed them different return values. Once you see it that way, it stops being weird: fork returns once per process, not once per call.

Copy-on-write makes it cheap

The naive read of fork — “duplicate the entire process’s memory” — would be ruinously expensive for a process holding gigabytes of state. It isn’t, because of copy-on-write:

1. After fork, parent and child share the same physical pages.
2. The kernel marks every page read-only in both processes’ page tables.
3. The first time either process writes to a page, the MMU traps, the kernel allocates a fresh physical page, copies the contents, and lets that process continue. Only the touched pages get duplicated.

So fork is roughly O(page-table size), not O(memory size). For a 16 GB PostgreSQL backend forking a worker, only the page table itself and a handful of dirtied pages get copied. This is why fork-heavy designs from the 1970s are still viable on machines a million times bigger than the PDP-11.

The fork+exec separation, and why it’s actually useful

The deep value of fork isn’t speed; it’s the gap between fork and exec. Between those two calls, the child is a fully-constructed process that hasn’t yet committed to a program. You can:

• Redirect file descriptors. dup2(pipe_fd, STDOUT_FILENO) in the child, before exec, is how shells wire up pipelines.
• Drop privileges. setuid() to a less privileged user before exec.
• Change directory, set environment variables, set resource limits, join a different process group.

A spawn-style API has to accept a giant struct with all of these as options — and Windows’ CreateProcess has 10 parameters, several of them themselves structs, partly for this reason. Fork-then-exec lets you configure the child by running ordinary code in it. That’s elegant, and it’s why POSIX kept fork even after posix_spawn was added as a faster alternative.

Show the seams

• Fork in a multithreaded process is treacherous. The child only inherits the calling thread. Every other thread vanishes — but their locks remain held in the child’s memory, leading to instant deadlocks if the child ever touches malloc (which itself uses locks). This is why POSIX restricts what you may legally do between fork and exec to “async-signal-safe” functions only. Many Python and PyTorch fork-related bugs trace back to this.
• The “fork is cheap” claim has a footnote: page-table size. Forking a process with very large memory (terabytes, common in databases or ML training) can take noticeable wall-clock time just to copy the page tables, even with COW. There’s a recurring kernel discussion about optimizing this; I don’t have a current status I’d quote.
• vfork is the historical optimization for “I’m going to exec immediately anyway, don’t bother setting up COW.” It’s still in POSIX but is widely considered dangerous; posix_spawn is the modern answer.
• macOS technically forks but discourages it. Apple’s frameworks (Grand Central Dispatch, anything that touches Mach ports) explicitly do not support being used after fork-without-exec. The platform expectation is fork-then-exec or posix_spawn.
• Containers complicate the story. clone() (Linux’s superset of fork) takes flags that say “and also give the child a new mount namespace, new network namespace, new PID namespace…” That’s how runc starts a container: it’s fork with extra arguments.

The shape to keep: fork is weird because it’s a clone primitive in a world that mostly builds spawn primitives. The clone separates “make a process” from “decide what it runs,” and that separation — not fork itself — is what proved durable.

Famous related terms

• exec — exec = replace this process's program + keep PID, fds, and other process attributes — the other half of the fork+exec pair.
• clone() — clone = fork + flags for which resources to share or namespace — Linux’s generalized fork; threads and containers are both clone calls with different flags.
• posix_spawn — posix_spawn ≈ fork + exec fused into one syscall + a file-actions list — the modern, portable alternative when you don’t need the gap.
• Copy-on-write — COW = share pages read-only + allocate on first write — the trick that makes fork cheap; also used by filesystems like ZFS and btrfs.
• vfork — vfork ≈ fork that shares the parent's address space until exec — historical speed hack, easy to misuse.
• Process — process = address space + file descriptors + scheduling state + PID — the unit fork duplicates.

Going deeper

• Dennis Ritchie, The Evolution of the Unix Time-sharing System — the primary source on why fork looks the way it does.
• Baumann, Appavoo, Krieger, Roscoe, A fork() in the road (HotOS 2019) — a polemic arguing fork should be retired, and a useful inventory of every weirdness it introduces.
• The Linux clone(2) man page — the cleanest specification of what fork actually does, generalized.