At-Fork Reset Hooks

## The API `os.register_at_fork(*, before=None, after_in_parent=None, after_in_child=None)` registers callables that CPython runs around every subsequent `os.fork()` and `os.forkpty()` performed by this interpreter. It has been available since Python 3.7, it exists only where `os.fork` does (Unix), all three arguments are keyword-only, and at least one of them must be supplied. It exists because a fork is not a fresh process: the child is a byte-for-byte copy of the parent's address space with exactly one thread running, so every cached handle, counter, seeded generator and half-updated data structure in that copy is inherited in whatever state the fork caught it in. ## Where each callback runs * `before` runs **in the parent, before the `fork()` syscall**. This is the only moment when you can still make the state that is about to be duplicated consistent: acquire the locks that guard it so no other thread can be mid-update when the snapshot is taken. * `after_in_parent` runs **in the parent, after `fork()` returns there**. Its job is to undo `before` — release what you acquired — so the parent carries on normally. * `after_in_child` runs **in the brand-new child process**. This is the repair phase: release the copy of the lock, drop handles that are not really yours (an inherited connection, a cached parent pid), and reseed a generator whose state is now identical to the parent's. Together they read like one nested block spanning the syscall, which is exactly the idiom the standard library itself uses: ```python import os import threading _lock = threading.Lock() os.register_at_fork( before=_lock.acquire, after_in_parent=_lock.release, after_in_child=_lock.release, ) ``` The `before` hook guarantees the fork cannot land while another thread holds `_lock`; both `after` hooks put each copy of the process back into a usable state. ## Ordering across several registrations Different libraries register independently, so order is defined: `before` callbacks fire in **reverse** registration order, while `after_in_parent` and `after_in_child` fire in registration order. The pair therefore unwinds like nested context managers, with the most recently registered hook on the outside. In practice registration order follows import order, so a library that imports another can rely on being unwound in a consistent sequence rather than an arbitrary one. ```pycon >>> import os >>> for i in range(3): ... os.register_at_fork(before=lambda i=i: print("before", i), ... after_in_child=lambda i=i: print("child", i)) ... >>> if os.fork() == 0: ... os._exit(0) ... before 2 before 1 before 0 child 0 child 1 child 2 ``` ## Failure and lifetime semantics Two properties surprise people. First, an exception raised inside a callback is **not** propagated and does not abort the fork: CPython reports it through `sys.unraisablehook` with the message `Exception ignored in atfork callback`, then runs the remaining callbacks and continues. A hook must therefore be defensive and independent of its neighbours — if it can raise, it will one day be swallowed into a log line nobody reads. Second, there is **no unregister**. A registration lasts for the life of the process and, because the registry lives in the address space, the child inherits it: if that child forks again, every hook runs again. Code that needs to stop participating must make its own callback a no-op behind a flag rather than expect to remove it. ## What actually triggers the hooks Only `os.fork()` and `os.forkpty()` from this interpreter. That covers `multiprocessing` when it uses the **fork** start method, since that is implemented on top of `os.fork()`. It does **not** cover the `spawn` or `forkserver` start methods, whose workers are separate interpreter startups that never saw your runtime registration, and it does not cover `subprocess` or `os.posix_spawn`, which fork-and-exec a different program — the Python-level callbacks are skipped there entirely. That boundary matters more since Python 3.14 changed the default `multiprocessing` start method on Linux to `forkserver` (macOS and Windows already defaulted to `spawn`): cleanup that only lives in an at-fork hook silently stops running when the start method changes. Initialization that must happen in *every* worker belongs in lazy per-worker setup; at-fork hooks are for repairing a copy, not for starting a process. ## Why an interviewer asks it The three-phase shape is the compact test of whether a candidate understands that a fork produces a *duplicate* rather than a *new* program. A candidate who can say which callback runs in which process, name the acquire-in-`before`/release-in-both idiom, and note that hooks are permanent, order-defined and non-fatal on error has demonstrated they have debugged this class of problem rather than read about it.