Skip to content

Conversation

@aggieNick02
Copy link

@aggieNick02 aggieNick02 commented Nov 15, 2022

long time (9 years).

We do this by using spawn.get_preparation_data() and then using the values in that dictionary appropriately. This lets us also fix the setting of sys.path (which never worked) and other minor properties of the forkserver process.

While updating the test to verify these fixes, we also discovered that forkserver was not flushing stdout/stderr before it forked to create a new process. This caused the updated test to fail because unflushed output in the forkserver would then be printed by the forked process as well. This is now fixed too.

…n for a

long time (9 years).

We do this by using spawn.get_preparation_data() and then using the
values in that dictionary appropriately. This lets us also fix the
setting of sys.path (which never worked) and other minor properties of
the forkserver process.

While updating the test to verify these fixes, we also discovered that
forkserver was not flushing stdout/stderr before it forked to create a
new process. This caused the updated test to fail because unflushed
output in the forkserver would then be printed by the forked process as
well. This is now fixed too.
@aggieNick02
Copy link
Author

One minor thing I noticed incase @pitrou remembers from several years ago. In Lib/test/mp_preload.py, the file begins with an import multiprocessing then multiprocessing.Lock() . Any idea what purpose the call to multiprocessing.Lock() serves? Some sort of required initialization?

@pitrou
Copy link
Member

pitrou commented Nov 16, 2022

@aggieNick02 I suppose it's a simple check that multiprocessing is usable from a preloaded module?

@aggieNick02
Copy link
Author

@aggieNick02 I suppose it's a simple check that multiprocessing is usable from a preloaded module?

Ah ok, thanks!

@brettcannon brettcannon removed their request for review November 16, 2022 21:47
@thesamesam
Copy link
Contributor

Is this one obsolete ("dupe" of #126631 and #135295)?

@gpshead
Copy link
Member

gpshead commented Nov 22, 2025

this one is obsolete due to the preloading of main being fixed. but the question of the buffering issue remains, lets take that up on the issue; there may be a new, now smaller, PR worth doing.

@gpshead gpshead closed this Nov 22, 2025
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Changes:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() to accept raise_exceptions parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag
- Add comprehensive test coverage in test_multiprocessing_forkserver
- Update documentation in Doc/library/multiprocessing.rst
- Add NEWS entry for Python 3.14
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
This change adds a keyword-only `raise_exceptions` parameter to
`multiprocessing.set_forkserver_preload()` that defaults to False
for backward compatibility. When set to True, ImportError exceptions
during module preloading in the forkserver process will be raised
instead of being silently ignored, causing the forkserver to exit
and breaking all use of the forkserver multiprocessing context.

This is similar in spirit to the approach attempted in pythonGH-99515,
providing developers with the ability to catch import errors during
forkserver module preloading for better debugging and error handling.

Implementation:
- Add _raise_exceptions attribute to ForkServer class
- Update set_forkserver_preload() in both forkserver.py and context.py
  to accept raise_exceptions keyword-only parameter
- Pass raise_exceptions flag through to forkserver main() function
- Update main() to conditionally raise ImportError based on flag

Tests:
- Create new test_multiprocessing_forkserver/test_preload.py with
  dedicated tests for raise_exceptions functionality
- Remove old test from _test_multiprocessing.py
- Add tests for both True/False cases and valid/invalid modules
- Ensure proper resource cleanup using try/finally

Documentation:
- Update Doc/library/multiprocessing.rst with detailed description
  of raise_exceptions behavior and consequences
- Add NEWS entry with contributor attribution
- Add Nick Neumann to Misc/ACKS

Contributed by Nick Neumann.
gpshead pushed a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.
gpshead added a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.

Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead added a commit to gpshead/cpython that referenced this pull request Nov 22, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.

Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead added a commit to gpshead/cpython that referenced this pull request Nov 23, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.

Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead added a commit to gpshead/cpython that referenced this pull request Nov 23, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.

Co-authored-by: aggieNick02 <nick@pcpartpicker.com>
Co-authored-by: Claude (Sonnet 4.5) <claude@anthropic.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
gpshead added a commit to gpshead/cpython that referenced this pull request Nov 23, 2025
Add a keyword-only `raise_exceptions` parameter (default False) to
`multiprocessing.set_forkserver_preload()`. When True, ImportError
exceptions during module preloading cause the forkserver to exit,
breaking all use of the forkserver multiprocessing context. This
allows developers to catch import errors during development rather
than having them silently ignored.

Implementation adds the parameter to both the ForkServer class method
and the BaseContext wrapper, passing it through to the forkserver
main() function which conditionally raises ImportError instead of
ignoring it.

Tests are in new test_multiprocessing_forkserver/test_preload.py with
proper resource cleanup using try/finally.

Documentation describes the behavior, consequences (forkserver exit,
EOFError/ConnectionError on subsequent use), and recommends use during
development.

Based on original work by Nick Neumann in pythonGH-99515.
Contributed by Nick Neumann.

Co-authored-by: aggieNick02 <nick@pcpartpicker.com>
Co-authored-by: Claude (Sonnet 4.5) <noreply@anthropic.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants