Explain the fork-then-exec model of creating a new process, including what copy-on-write does, and why creating a process is normally more expensive than creating a thread.

## The two-step model Many operating systems create processes in two moves rather than one. **Fork** produces a near-identical duplicate of the calling process. The child receives a copy of the parent's address space, a copy of the open-handle table, the same working directory and credentials, and resumes at exactly the same instruction. The only difference visible to the code is the return value: the parent learns the child's identifier, the child learns it is the child. **Exec** keeps the process — same identifier, same handle table, same credentials — but throws away its memory image and loads a different executable in its place. Exec does not return on success; the old program is simply gone. Combining them gives "create a process running program X": fork, then in the child, exec X. ## Why split it at all The gap between the two calls is the point. Between fork and exec the child is running your code with the new process's identity, so it can: - redirect its standard input/output to a pipe or file, which is exactly how a shell wires `a | b`; - close handles the new program should not inherit; - drop privileges, change working directory, set resource limits, join a sandbox. A single all-in-one "spawn program with these settings" call has to expose every one of those knobs as parameters. The two-step model expresses them as ordinary code. The cost is that the composed operation is not atomic and inherits some awkward semantics — most notably, what a fork means when the parent has many threads. ## Copy-on-write Duplicating an address space eagerly would be absurd for a parent holding gigabytes. **Copy-on-write** makes the duplication lazy: 1. Fork copies the page *tables*, not the pages. 2. Every writable page in both processes is marked read-only, and the physical page is referenced by both. 3. A write to such a page traps. The kernel allocates a fresh physical page, copies the contents, remaps it writable for the writer, and lets the instruction retry. So the copy cost is proportional to the pages actually modified, not to the address space size. When the child execs immediately — the common case — almost nothing is copied and the whole image is discarded anyway. This also means fork's cost scales with the *number of pages mapped* (page-table work) rather than with the bytes resident, and that a large, write-heavy parent can pay a surprising trickle of copy faults after forking. ## Forking a multi-threaded parent Only the calling thread survives into the child; the others simply do not exist there. Anything they were holding — a lock, a half-updated data structure — is frozen in that state in the child's copy. That is why forking from a multi-threaded program and then doing anything other than exec is a well-known hazard: the child can deadlock on a mutex whose owning thread never existed. The safe discipline is fork, then exec, with minimal work in between. ## Why a process costs more than a thread Creating a thread inside an existing process means: allocate a stack, allocate a small control block, register it with the scheduler. Creating a process means at minimum: allocate and initialize page tables, build a handle table, set up accounting and identity, and — if you then exec — parse an executable, map its segments, resolve dynamic libraries, and start from a cold instruction and data cache. The cost does not stop at creation: - **Switching** between processes changes address spaces, which can invalidate address-translation caches and force them to be re-populated; switching between threads of one process does not. - **Memory footprint** per process includes its own page tables and runtime, not just a stack. - **Communication** across processes copies bytes; across threads it passes a reference. A reasonable mental ordering, without pretending to exact numbers: thread creation is cheap, process creation via fork is meaningfully more expensive, and fork plus exec plus program startup is the expensive one — which is why systems that need many short-lived workers pre-fork a pool at startup and reuse it, and why a request path should never shell out per request if it can avoid it. ## The alternative model Not every system forks. The other common design is a single "create a process from this executable with this configuration" call that never duplicates the parent. It avoids the multi-threaded-fork hazard and the copy-on-write machinery entirely, at the cost of a larger, more parameterized interface. Knowing both models — and that fork's cheapness is entirely due to laziness — is the level of understanding an interviewer is after.