Occasionally `multiprocessing.test.*.test_threads` can take 10 minutes

[gpshead]

Bug report

Bug description:

See the logs in https://buildbot.python.org/all/#/builders/1138/builds/498

10 slowest tests:
- test.test_multiprocessing_spawn.test_threads: 10 min 14 sec
- test.test_multiprocessing_fork.test_threads: 10 min 13 sec
- test_imaplib: 1 min 31 sec
- test_signal: 1 min 18 sec
- test.test_multiprocessing_spawn.test_processes: 52.6 sec
- test.test_concurrent_futures.test_wait: 48.6 sec
- test_socket: 40.7 sec
- test.test_multiprocessing_forkserver.test_processes: 40.1 sec
- test_io: 37.4 sec
- test_codecs: 37.3 sec

Normally those two .test_threads sub-suites in test_multiprocessing do not make the top 10 slowest at all.

Something odd is going on and occasionally making them sit around for a very long time before apparently succeeding anyways. I've seen it multiple time in the rpi buildbot logs. I expect it'll show up on some other bots as well but I haven't gone hunting.

CPython versions tested on:

3.12

Operating systems tested on:

Linux

Linked PRs

• gh-113205: test_multiprocessing.test_terminate: Test the API on threadpools #114186
• [3.12] gh-113205: test_multiprocessing.test_terminate: Test the API on threadpools (GH-114186) #114222
• [3.11] gh-113205: test_multiprocessing.test_terminate: Test the API on threadpools (GH-114186) #114223
• gh-113205: test_multiprocessing.test_terminate: Give tasks a chance to start #114249
• [3.12] gh-113205: test_multiprocessing.test_terminate: Give tasks a chance to start (GH-114249) #114516
• [3.11] gh-113205: test_multiprocessing.test_terminate: Give tasks a chance to start (GH-114249) #114517

[gpshead]

Notably I'm not seeing this on the main 3.x branch builds, only 3.12 and 3.11. https://buildbot.python.org/all/#/workers/25

[encukou]

It appears on Windows too, and there the refleak buildbot sometimes fails with a timeout.

I will investigate.

[encukou]

WithThreadsTestPool.test_terminate takes LONG_TIMEOUT (5 minutes) in about 1.5% cases (on my machine).

It happens when the first task starts executing before termination. Unlike processes, threads can't be safely forcefully stopped, so the expected behaviour of ThreadPool.terminate is to wait for in-progress tasks to finish.
But the test is designed for process pools, and it uses very long tasks.

On main, the test is now skipped for threads entirely. We can do better: for threads, use a shorter task, but still make sure the API works.