Skip to content

[3.13] gh-117378: Fix multiprocessing forkserver preload sys.path inheritance. (GH-126538) #126632

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Nov 9, 2024

Conversation

miss-islington
Copy link
Contributor

gh-117378: Fix multiprocessing forkserver preload sys.path inheritance.

sys.path was not properly being sent from the parent process when launching
the multiprocessing forkserver process to preload imports. This bug has been
there since the forkserver start method was introduced in Python 3.4. It was
always supposed to inherit sys.path the same way the spawn method does.

Observable behavior change: A '' value in sys.path will now be replaced in
the forkserver's sys.path with an absolute pathname
os.path.abspath(os.getcwd()) saved at the time that multiprocessing was
imported in the parent process as it already was when using the spawn start
method. This will only be observable during forkserver preload imports.

The code invoked before calling things in another process already correctly sets sys.path.
Which is likely why this went unnoticed for so long as a mere performance issue in
some configurations.

A workaround for the bug on impacted Pythons is to set PYTHONPATH in the
environment before multiprocessing's forkserver process was started. Not perfect
as that is then inherited by other children, etc, but likely good enough for many
people's purposes.

(cherry picked from commit 9d08423)

Co-authored-by: Gregory P. Smith [email protected]
Co-authored-by: Serhiy Storchaka [email protected]

…ritance. (pythonGH-126538)

pythongh-117378: Fix multiprocessing forkserver preload sys.path inheritance.

`sys.path` was not properly being sent from the parent process when launching
the multiprocessing forkserver process to preload imports.  This bug has been
there since the forkserver start method was introduced in Python 3.4.  It was
always _supposed_ to inherit `sys.path` the same way the spawn method does.

Observable behavior change: A `''` value in `sys.path` will now be replaced in
the forkserver's `sys.path` with an absolute pathname
`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` was
imported in the parent process as it already was when using the spawn start
method. **This will only be observable during forkserver preload imports**.

The code invoked before calling things in another process already correctly sets `sys.path`.
Which is likely why this went unnoticed for so long as a mere performance issue in
some configurations.

A workaround for the bug on impacted Pythons is to set PYTHONPATH in the
environment before multiprocessing's forkserver process was started. Not perfect
as that is then inherited by other children, etc, but likely good enough for many
people's purposes.

(cherry picked from commit 9d08423)

Co-authored-by: Gregory P. Smith <[email protected]>
Co-authored-by: Serhiy Storchaka <[email protected]>
@bedevere-app bedevere-app bot added topic-multiprocessing type-bug An unexpected behavior, bug, or error labels Nov 9, 2024
@gpshead gpshead merged commit 4e036d3 into python:3.13 Nov 9, 2024
40 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
topic-multiprocessing type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants