Why does CPython raise a DeprecationWarning for os.fork() in a multi-threaded process?

### What the warning is Since **Python 3.12**, calling `os.fork()` or `os.forkpty()` from a process that has more than one running thread raises a `DeprecationWarning`. Nothing else about the call changes: the fork still happens, the child still runs. The warning is a signal that this specific *combination* — forking plus threads — is a bug pattern the language is steering people away from, and it is the visible front of a multi-release migration whose other half landed in 3.14. Note what is **not** deprecated. `os.fork()` in a single-threaded process is an ordinary, supported Unix operation and emits nothing. The warning is conditional on the state of the process at the moment of the call. ### Why the combination is unsafe `fork()` copies the address space but creates the child with only one thread of control: the caller. Every other thread ceases to exist in the child, while all the memory those threads were working on arrives intact and mid-flight. The dangerous case is a lock. A lock that some other thread held at the instant of the fork is copied in the **held** state, and the thread that would have released it is not in the child. Nothing will ever release it, so the child's first attempt to acquire that lock blocks forever. There is no exception, no traceback, no exit code — just a process that stops. You rarely hit this through a lock you wrote. The locks that bite are the ones inside machinery you did not think about: - a `logging.Handler`'s lock, taken around every emitted record; - the import system's per-module locks, taken by any lazy `import` in the child; - a buffered writer's internal lock; - the memory allocator's own lock, which means even ordinary object creation can hang; - a connection pool's or a cache's internal structures. Which of those is locked at fork time is decided by the OS scheduler, so the failure is probabilistic and grows more likely the busier the parent's threads are — which is exactly why it tends to appear first in production and not in a test. POSIX has always said this outright: in the child of a fork from a multi-threaded process, only async-signal-safe functions may be called before `exec`. Python cannot honour that restriction — allocating an object takes a lock — so the only genuinely safe post-fork paths are "immediately exec" or "do nothing that touches inherited state". ### What Python 3.14 changed On **Python 3.14** the `multiprocessing` default start method is `forkserver` on Linux and other Unix platforms; **macOS and Windows default to `spawn`** (macOS has done so since 3.8), and `fork` must now be requested explicitly with `multiprocessing.set_start_method` or `multiprocessing.get_context`. `concurrent.futures.ProcessPoolExecutor` follows the same default because it uses `multiprocessing`'s context. `forkserver` addresses the thread problem structurally rather than by warning about it: a small helper process is started early, and every worker is forked from **that** process, which is single-threaded and does almost nothing. Your threaded parent is never the thing being forked. The price is that children no longer inherit state created after the helper started, so anything a worker needs must be picklable or re-created — a real cost, and the reason the change waited for a major release. (Choosing between the start methods on their broader merits belongs to the concurrency material; here the point is only that the default moved *because of threads*.) ### Seeing the warning at all `DeprecationWarning` is ignored by default outside `__main__`, so a service can be forking unsafely for years in silence. Make it visible deliberately: run with `-X dev`, or set `PYTHONDEVMODE=1` or `PYTHONWARNINGS=default::DeprecationWarning` in the environment, or call `warnings.simplefilter("default", DeprecationWarning)` during startup — and call `logging.captureWarnings(True)` so the message lands in the logs you actually read rather than on a stderr nobody collects. ### The response an interviewer wants Not "silence the warning". The warning is telling you that the process forks after it has grown threads, and the fixes are structural: 1. Fork before starting threads — build the process pool during startup, ahead of metrics, health-check and logging threads. 2. Or don't fork your process at all: take the 3.14 default of `forkserver`, or `spawn`. 3. Or, if the child immediately calls one of the `exec` family (`os.execv` and friends), the child's inherited locks never matter, because the whole address space is replaced. Suppressing the warning leaves you with a deadlock that appears under load, in a child, with no stack — one of the more expensive bugs to chase.