What distinguishes multiprocessing's fork, spawn and forkserver start methods, and which is default where?

The three start methods differ in one thing — where the child's initial state comes from — and everything else follows from that. ### fork The child is a copy of the parent's address space at the moment of the call. Every module already imported is there, every module-level object is there, open file objects are there, and start-up cost is a fraction of a millisecond because nothing is imported or pickled. Copy-on-write means large read-only data structures appear free at first, though CPython's reference counts live inside the object headers, so merely *touching* inherited objects dirties their pages and the sharing erodes. The cost is correctness. `fork` duplicates only the calling thread: any other thread simply does not exist in the child, and any lock those threads were holding stays locked forever. It also duplicates things that are not safe to duplicate — pooled connections, buffered file objects with unflushed data, cryptographic random state, and runtimes below CPython that assume a single process. `fork` is only available on Unix. ### spawn The child is a brand-new interpreter, started from `sys.executable`, that imports the parent's main module and unpickles a small payload describing the target callable and its arguments. It inherits nothing, so it is immune to the fork hazards, and it is the only method Windows supports. The price is start-up time — a fresh interpreter plus a full import of your application's module graph, which for an import-heavy program can be hundreds of milliseconds per worker — and a stricter contract: the main module needs a `if __name__ == "__main__":` guard, and everything the worker receives must be picklable. ### forkserver On first use the parent starts a dedicated server process, then every worker is forked from that server rather than from the parent. Because the server is created early and is single-threaded, the forked children never inherit application threads or their held locks. Because forking is still just a fork, worker creation stays cheap. The server starts nearly empty, so a worker only has whatever the server imported; `multiprocessing.set_forkserver_preload([...])` names modules to import into the server once, so the fork gives every worker those imports for free. Like `spawn`, `forkserver` imports the main module in the worker and requires the guard, and arguments must be picklable. It is Unix-only. ### Defaults, and how they got that way On CPython 3.14, `multiprocessing.get_start_method()` returns `forkserver` on Unix platforms other than macOS, and `spawn` on macOS and Windows. macOS moved to `spawn` in 3.8, because forking a process that has touched higher-level system frameworks tends to crash the child. Python 3.12 began emitting a `DeprecationWarning` when the implicit default `fork` was used from a multi-threaded parent, and 3.14 completed the retreat by changing the default outright. `fork` remains available on Unix; you now have to request it. `multiprocessing.get_all_start_methods()` reports what the running platform supports. ### Choosing Use `spawn` when you need cross-platform behaviour, when the parent is threaded or embeds another runtime, or when you want children whose state is exactly what you passed them. Use `forkserver` on Linux when worker churn matters — many short-lived workers, or a pool that recycles workers — and preload the heavy modules. Reach for `fork` only in a deliberately single-threaded parent where inheriting a large in-memory structure without re-loading it is the point, and even then know that you are opting out of the default for a reason you can state. ### The state-inheritance trap The most common surprise when moving off `fork` is not a crash but a wrong answer. Under `fork`, a module-level list, cache or configuration object that the parent mutated after import arrives in the child already populated; under `spawn` or `forkserver`, the child re-imports the module and sees only the value that the import itself created. A route-optimisation job that builds a distance table at start-up and mutates a module-level default in `main()` will happily produce different routes per worker after an upgrade changes the start method — with no exception anywhere. Pass such state explicitly as an argument, or rebuild it in a pool initializer, instead of relying on inheritance.