Repository navigation
[3.15] gh-155717: Determine multiprocessing's default start method lazily (GH-159254) - #159271
Merged
Merged
Conversation
…hod lazily (pythonGH-159254) pythongh-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 pythongh-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 python#155717 (comment) (cherry picked from commit 48ddda1) Co-authored-by: Vyron Vasileiadis <hi@fedonman.com>
…hange Say that the change applies when there is no writable temporary directory and that starting a process previously failed there.
gpshead
enabled auto-merge (squash)
October 12, 2026 22:45
gpshead
disabled auto-merge
October 12, 2026 22:49
gpshead
enabled auto-merge (squash)
October 12, 2026 22:53
Documentation build overview
142 files changed ·
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gh-155827 made
import multiprocessingcheck 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 inmultiprocessing.util,subprocess,tempfile,shutilandrandom, 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 defaultProcessstart.multiprocessing.utilgoes back to importingtempfileonly where it is used.Also include the fix from gh-158410 by Vyron Vasileiadis, along with a test adapted from that PR: when
tempfilefinds no usable temporary directory at all, the check now reports that instead of raisingFileNotFoundError, 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 changedforkserverto be added to_concrete_contextsconditionally onreduction.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.