…ritance. (pythonGH-126538)pythongh-117378: Fix multiprocessing forkserver preload sys.path inheritance.`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.(cherry picked from commit9d08423)Co-authored-by: Gregory P. Smith <greg@krypto.org>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…eritance. (GH-126538) (GH-126632)gh-117378: Fix multiprocessing forkserver preload sys.path inheritance. (GH-126538)`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.(cherry picked from commit9d08423)Co-authored-by: Gregory P. Smith <greg@krypto.org>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…th inheritance. (pythonGH-126538)pythongh-117378: Fix multiprocessing forkserver preload sys.path inheritance.`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.(cherry picked from commit9d08423)Co-authored-by: Gregory P. Smith <greg@krypto.org>Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…eritance. (GH-126538) (GH-126633)gh-117378: Fix multiprocessing forkserver preload sys.path inheritance.`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.(cherry picked from commit9d08423)Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…ritance. (pythonGH-126538)pythongh-117378: Fix multiprocessing forkserver preload sys.path inheritance.`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>

…ritance. (pythonGH-126538)pythongh-117378: Fix multiprocessing forkserver preload sys.path inheritance.`sys.path` was not properly being sent from the parent process when launchingthe multiprocessing forkserver process to preload imports.  This bug has beenthere since the forkserver start method was introduced in Python 3.4.  It wasalways _supposed_ to inherit `sys.path` the same way the spawn method does.Observable behavior change: A `''` value in `sys.path` will now be replaced inthe forkserver's `sys.path` with an absolute pathname`os.path.abspath(os.getcwd())` saved at the time that `multiprocessing` wasimported in the parent process as it already was when using the spawn startmethod. **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 insome configurations.A workaround for the bug on impacted Pythons is to set PYTHONPATH in theenvironment before multiprocessing's forkserver process was started. Not perfectas that is then inherited by other children, etc, but likely good enough for manypeople's purposes.Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>