Creating Processes: fork, exec, wait

fork() is called once and returns twice: in the parent it returns the child’s PID, in the child it returns 0. At the instant of return the two processes are identical except for that return value, the PID, and a few accounting fields: same code, same variables with the same values, same open descriptors pointing at the same underlying files (and sharing their offsets), same signal dispositions, same working directory. From then on they diverge; a write to a variable in one is invisible to the other.

The kernel does not copy the memory. It copies the page tables and marks every writable page copy-on-write: both processes share the physical pages read-only until one writes, at which point that one page is duplicated (see Copy-on-Write). A fork of a 2 GB process therefore costs microseconds to low milliseconds — proportional to the number of page-table entries, not the number of bytes — plus later, scattered page faults as the child starts writing. It also means a fork from a multi-threaded process is dangerous: only the calling thread is cloned, and any lock another thread held at that instant is held forever in the child. That is why the rule is "only exec after fork in a multi-threaded program", and why glibc’s posix_spawn and Python’s spawn start method exist.

The exec family (execve is the system call; execl, execvp and friends are libc conveniences that search PATH or build the argument list) throws away the calling process’s address space and builds a new one from an executable, as described in Follow a Program: from `./server` to the First Instruction. The process keeps its PID, its parent, its descriptors (except those marked close-on-exec, O_CLOEXEC), its working directory, its uid — and loses its memory, its threads, its signal handlers and its pending atexit functions. exec never returns on success; if you see the line after it, it failed.

The window between fork and exec is where the parent shapes the child: dup2 a pipe onto descriptor 1 so the child’s stdout flows to the parent, chdir, setuid to drop privileges, setrlimit to cap memory, close descriptors the child should not inherit. Every subprocess library’s cwd=, env=, stdout=PIPE, uid= option is a call inserted into this window. Descriptors that are *not* marked close-on-exec leak into the child, which is the mechanism behind "the port is still in use after the server exited" — a child it spawned inherited the listening socket.

A process ends by returning from main, calling exit(n), or being killed by a signal. The kernel frees its memory and descriptors immediately but keeps the process record with the exit status until the parent calls wait() or waitpid(). Until then the child is a zombie: visible in ps as <defunct>, consuming a PID and nothing else. A parent that spawns children and never waits accumulates zombies until fork fails with EAGAIN. The fix is in the parent: waitpid(-1, …, WNOHANG) in a SIGCHLD handler, or ignore SIGCHLD explicitly, which tells the kernel to auto-reap.

If the parent exits first, the children are orphans: still running, re-parented to PID 1 (or the nearest subreaper), which reaps them when they exit. Orphans are not a leak in themselves — a daemon deliberately orphans itself to detach from the terminal — but they are the mechanism behind "I killed the server and its workers are still serving". Killing a process does not kill its children unless you kill the process group (kill -- -PGID) or use a cgroup.

Exit codes are 8-bit: 0 means success by convention, 1–255 mean whatever the program says, and a signal death is reported separately (WIFSIGNALED). Shells encode signal death as 128 + signal number, so exit status 137 is SIGKILL (128 + 9) — usually the OOM killer or a container runtime — and 139 is SIGSEGV (128 + 11).

Windows builds a process directly from an executable path: CreateProcess(application, commandLine, …, &startupInfo, &processInfo) creates the process object, its address space, and its first thread in one call, returning handles to both. There is no clone step and so no copy-on-write duplication of the parent; handle inheritance must be requested per handle (bInheritHandles plus a SECURITY_ATTRIBUTES flag on each), and stdin/stdout/stderr are set via fields in STARTUPINFO. The parent waits with WaitForSingleObject(hProcess) and reads the code with GetExitCodeProcess, which is 32-bit, not 8-bit.

There are no zombies in the Unix sense — the process object is released when the last handle to it is closed — but a parent that never closes the handle keeps the object alive in the same way. There is no process tree semantics by default either: killing a parent does not affect children unless they were placed in a Job Object with kill-on-close, which is the Windows equivalent of a cgroup for this purpose. Windows also has no exec: replacing a program means starting a new process and exiting.

Every runtime’s subprocess API is the fork/exec/wait (or CreateProcess/WaitForSingleObject) sequence with the pipe plumbing done for you. Python’s subprocess.run(["ffmpeg", …], capture_output=True, timeout=30) forks (on Linux via posix_spawn or vfork where possible for speed), sets up pipes, execs, reads both pipes concurrently, waits, and raises on timeout after killing the child. Node’s child_process.spawn does the same through libuv, delivering stdout as a stream; exec buffers it; fork is spawn of another Node with an IPC channel. C++ has only std::system, which runs /bin/sh -c (or cmd.exe) and returns the shell’s status — use posix_spawn or the platform API for anything real.

Two bugs recur in every language. First, reading only stdout while the child fills stderr’s pipe: the pipe buffer (64 kB on Linux) fills, the child blocks on write, the parent blocks on read — a deadlock. Libraries that offer communicate() or capture_output read both concurrently for this reason. Second, timeouts that kill the child but not its grandchildren (sh -c "…" spawns the real command): use a process group or a job object, or avoid the shell.