gh-146313: Fix multiprocessing ResourceTracker deadlock after os.fork()

[gpshead]

Problem

ResourceTracker.__del__ (added in gh-88887) calls os.waitpid(pid, 0) which blocks indefinitely if a process created via os.fork() still holds the tracker pipe's write end. The tracker never sees EOF, never exits, and the parent hangs at interpreter shutdown.

Root cause

Three requirements conflict:

• multiprocessing: the Resource Tracker process is never reaped #88887 wants the parent to reap the tracker to prevent zombies
• semaphore_tracker is not reused by child processes #80849 wants mp.Process(fork) children to reuse the parent's tracker via the inherited pipe fd
• multiprocessing ResourceTracker can deadlock at shutdown when os.fork was used #146313 shows the parent can't block in waitpid() if a child holds the fd -- the tracker won't see EOF until all copies close

Fix

Two layers:

Timeout safety-net. _stop_locked() gains a wait_timeout parameter. When called from __del__, it polls with WNOHANG using exponential backoff for up to 1 second instead of blocking indefinitely.

At-fork handler. An os.register_at_fork(after_in_child=...) handler closes the inherited pipe fd in the child unless a preserve flag is set. popen_fork.Popen._launch() sets the flag before its fork so mp.Process(fork) children keep the fd and reuse the parent's tracker (preserving gh-80849). Raw os.fork() children close the fd, letting the 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 (gh-88887 scenario)	~30ms reap	~30ms reap

The at-fork handler makes the timeout unreachable in all well-behaved paths. The timeout remains as a safety net for abnormal shutdowns.

[itamaro]

mostly nits, overall looks good, thanks!

[bedevere-app]

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

[bedevere-bot]

🤖 New build scheduled with the buildbot fleet by @gpshead for commit b7d3b38 🤖

Results will be shown at:

https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F146316%2Fmerge

If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again.

[gpshead]

while waiting for buildbots before hitting merge... stashing my porposed commit message:

commit message body

ResourceTracker.__del__ (added in gh-88887 circa Python 3.12) calls
os.waitpid(pid, 0) which blocks indefinitely if a process created via os.fork()
still holds the tracker pipe's write end. The tracker never sees EOF, never
exits, and the parent hangs at interpreter shutdown.

Fix with two layers:

• At-fork handler. An os.register_at_fork(after_in_child=...)
  handler closes the inherited pipe fd in the child unless a preserve
  flag is set. popen_fork.Popen._launch() sets the flag before its
  fork so mp.Process(fork) children keep the fd and reuse the parent's
  tracker (preserving semaphore_tracker is not reused by child processes #80849). Raw os.fork() children close the fd,
  letting the parent reap promptly.

• Timeout safety-net. _stop_locked() gains a wait_timeout
  parameter. When called from __del__, it polls with WNOHANG using
  exponential backoff for up to 1 second instead of blocking
  indefinitely. The at-fork handler makes this unreachable in
  well-behaved paths; it remains for abnormal shutdowns.

Co-authored-by: Itamar Oren itamarost@gmail.com

[miss-islington-app]

Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖

[bedevere-app]

GH-148425 is a backport of this pull request to the 3.14 branch.

[bedevere-app]

GH-148426 is a backport of this pull request to the 3.13 branch.