gh-155827 made import multiprocessing check whether the temporary directory is writeable in order to choose between "forkserver" and "spawn" as the default start method. That check ran at import time and pulled in multiprocessing.util, subprocess, tempfile, shutil and random, noticeably slowing down the import for every program, including ones that never start a process and every spawned child, the fork server and the resource tracker.

The default start method is now determined the first time it is needed instead: on the first get_context(), get_start_method(), get_all_start_methods() or default Process start. multiprocessing.util goes back to importing tempfile only where it is used.

Also include the fix from gh-158410 by Vyron Vasileiadis, along with a test adapted from that PR: when tempfile finds no usable temporary directory at all, the check now reports that instead of raising FileNotFoundError, so that "spawn" is chosen.

The regression was reported, and the lazy approach suggested, by Leandro Damascena in
#155717 (comment)

(cherry picked from commit 48ddda1) backport of #159254

Manual backport notes (3.15)

The automated backport conflicted in Lib/multiprocessing/context.py. main has gh-149879 (the Cygwin test fix), which is not on 3.15 and which changed forkserver to be added to _concrete_contexts conditionally on reduction.HAVE_SEND_HANDLE. 3.15 still lists it unconditionally in the dict literal, and this change rewrites the lines directly below it.

Resolution: kept 3.15's unconditional 'forkserver': ForkServerContext() entry and did not bring over the conditional registration from gh-149879.

We also reword the NEWS entry here, an equivalent rewording has landed on main.

• Issue: forkserver requires a writeable temp file system #155717