Why does a metrics scraper's __main__ module body re-run inside every spawned worker process?

## What the child actually has to rebuild When `multiprocessing` starts a worker with `fork`, the child is a copy of the parent's address space: every module already imported, every global already built. Nothing needs re-running. Under `spawn` and `forkserver` the child is a *fresh interpreter* — it shares no objects with the parent at all. To run your target callable it must unpickle it, and a function pickles **by reference**: module name plus qualified name. If the callable was defined in the parent's `__main__` module, the child has to produce a module that contains it. It does that by locating the parent's main file and executing it again in the child. Crucially, it executes it under a **substitute module name that `multiprocessing` reserves for exactly this purpose**, not under `"__main__"`. That single detail explains the whole behaviour: - Everything at module level — imports, constants, class and function definitions, and any side effects — **runs again, in every child**. - Everything inside `if __name__ == "__main__":` — **does not**, because the comparison is false there. ## Why this now bites almost everyone In Python 3.14 the default start method on Unix platforms other than macOS became `forkserver`; macOS and Windows already defaulted to `spawn`, and `fork` must now be requested explicitly. `forkserver` forks from a clean server process that does not carry your application state, so it re-imports the main module just as `spawn` does. Code that quietly relied on `fork`'s copied memory on Linux — module-level singletons, an already-open pool, a populated cache — changes behaviour on 3.14 without a line of it being edited. For a team sharing one CLI, that shows up as "it works on the release box and not on mine", because the two platforms had different defaults for years. ## The failure shape to recognise A metrics scraper whose module body builds a collector and then hands it out as a default argument is the compact version of the bug: ```python import os SEEN = [] # rebuilt in every re-import of this module print("module body, pid", os.getpid()) def collect(sample, seen=SEEN): seen.append(sample) return len(seen) ``` In a single process this is the familiar shared-mutable-default idiom: one list, bound once at `def` time, growing across calls. Fan the scraper out across eleven workers and every child re-executes the module body, so every child binds a *different* fresh list as the default. Deduplication that "worked" silently stops working, each worker re-scrapes what another already had, counts come back low, and nothing raises. The banner printed at module level appears once per worker, which is usually the first visible clue. The other classic symptom is recursion: if a worker is started at module level with no guard, the child re-executes the body, which starts another worker, and so on. `multiprocessing` detects this and raises a `RuntimeError` whose message tells you to add the `__name__` guard — and mentions `multiprocessing.freeze_support()`, which is the extra call a frozen executable needs. ## What to do about it 1. **Guard all startup.** Argument reading, logging configuration, connections, timers, process creation: below the line. `multiprocessing.Process` must never be constructed at module level. 2. **Keep module bodies cheap and pure.** Definitions and small constants only. Anything that costs time is paid once per worker, so an expensive module body turns into a slow, mysteriously CPU-hungry startup for a big pool. 3. **Pass state explicitly.** Do not treat a module-level object as shared: with a fresh-interpreter start method there is no sharing, and each worker gets its own copy of whatever the module body built. Send the data as arguments, or use an explicit shared mechanism. 4. **Beware what module-level code touches.** An open file descriptor, a logging handler pointed at the same file, or a random seed fixed at module level is now created once per worker, with all the interleaving that implies. 5. **Do not "fix" it by requesting `fork`.** It removes the symptom by reintroducing the hazards that motivated the default change — forking a process with threads or held locks is the reason `forkserver` became the default in the first place. ## The interview answer Name the cause (a fresh interpreter that must rebuild the main module by re-executing its file), name the precise consequence (module body yes, guarded block no, because the child binds a substitute module name), and name the fix (thin, pure module bodies with everything else behind the guard). Mention that 3.14 changed the Unix default to `forkserver`, so this is now the normal case rather than a Windows quirk.