ProblemResourceTracker.__del__ (added inpythongh-88887) calls os.waitpid(pid, 0)which blocks indefinitely if a process created via os.fork() stillholds the tracker pipe's write end. The tracker never sees EOF, neverexits, and the parent hangs at interpreter shutdown.Root causeThree requirements conflict:-pythongh-88887 wants the parent to reap the tracker to prevent zombies-pythongh-80849 wants mp.Process(fork) children to reuse the parent's  tracker via the inherited pipe fd-pythongh-146313 shows the parent can't block in waitpid() if a child  holds the fd -- the tracker won't see EOF until all copies closeFixTwo layers:Timeout safety-net. _stop_locked() gains a wait_timeout parameter.When called from __del__, it polls with WNOHANG using exponentialbackoff for up to 1 second instead of blocking indefinitely.At-fork handler. An os.register_at_fork(after_in_child=...) handlercloses the inherited pipe fd in the child unless a preserve flag isset. popen_fork.Popen._launch() sets the flag before its fork somp.Process(fork) children keep the fd and reuse the parent's tracker(preservingpythongh-80849). Raw os.fork() children close the fd, lettingthe parent reap promptly.Result  Scenario                                       Before     After  Raw os.fork(), parent exits while child alive  deadlock   ~30ms reap  mp.Process(fork), parent joins then exits      ~30ms reap ~30ms reap  mp.Process(fork), parent exits abnormally      deadlock   1s bounded wait  No fork (pythongh-88887 scenario)                    ~30ms reap ~30ms reapThe at-fork handler makes the timeout unreachable in all well-behavedpaths. The timeout remains as a safety net for abnormal shutdowns.