]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
gh-117378: Fix multiprocessing forkserver preload sys.path inheritance. (GH-126538)
authorGregory P. Smith <greg@krypto.org>
Sat, 9 Nov 2024 23:01:32 +0000 (15:01 -0800)
committerGitHub <noreply@github.com>
Sat, 9 Nov 2024 23:01:32 +0000 (23:01 +0000)
commit9d08423b6e0fa89ce9cfea08e580ed72e5db8c70
tree8015792119dca3a44c267e578d1799a12f654bad
parent266328552e922fd9030cd699e10a25f03a67c8ba
gh-117378: Fix multiprocessing forkserver preload sys.path inheritance. (GH-126538)

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.

Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
Lib/multiprocessing/forkserver.py
Lib/test/_test_multiprocessing.py
Misc/NEWS.d/next/Library/2024-11-07-01-40-11.gh-issue-117378.o9O5uM.rst [new file with mode: 0644]