gh-157184: Scale the join() alarm in the multiprocessing kill tests

_kill_process() interrupts the join() of the killed child with SIGALRM so
that a blocked waitpid() becomes a readable error instead of a hang, but
the alarm has been a fixed 10 seconds since 2013. On a build slow enough
that reaping the child legitimately takes longer, it fires on a healthy
run: seen on the UBSan CI job, where the alarm interrupted os.waitpid()
itself.

Use support.LONG_TIMEOUT, which is documented for detecting hangs and is
scaled by regrtest for slow workers, as the same function already does
for its event wait.

Author: iamsharduld

Lib/test/_test_multiprocessing.py

@@ -9,6 +9,7 @@
 import time
 import io
 import itertools
+import math
 import sys
 import os
 import gc
@@ -624,11 +625,14 @@ def _kill_process(self, meth, target=None):
         if hasattr(signal, 'alarm'):
             # On the Gentoo buildbot waitpid() often seems to block forever.
             # We use alarm() to interrupt it if it blocks for too long.
+            # The timeout only has to catch a hang, so use LONG_TIMEOUT:
+            # a shorter one fires on a slow build where reaping the child
+            # legitimately takes a while.
             def handler(*args):
                 raise RuntimeError('join took too long: %s' % p)
             old_handler = signal.signal(signal.SIGALRM, handler)
             try:
-                signal.alarm(10)
+                signal.alarm(math.ceil(support.LONG_TIMEOUT))
                 self.assertEqual(join(), None)
             finally:
                 signal.alarm(0)

Misc/NEWS.d/next/Tests/2026-09-08-14-05-00.gh-issue-157184.nKPZhX.rst

@@ -0,0 +1,5 @@
+Fix the ``multiprocessing`` tests that kill a child process
+(``test_interrupt``, ``test_interrupt_no_handler``, ``test_terminate`` and
+``test_kill``) failing on slow builds: the alarm guarding the ``join()`` of
+the killed child used a fixed 10 second timeout, and now uses
+:data:`~test.support.LONG_TIMEOUT`, which regrtest scales.