Commit Graph

18 Commits

Author SHA1 Message Date
Gregory P. Smith ee5318025b gh-140814: Fix freeze_support() setting start method as side effect (GH-144608)
freeze_support() called get_start_method() without allow_none=True,
which locked in the default start method context. This caused a
subsequent set_start_method() call to raise "context has already been
set". Use allow_none=True and accept None as a matching value, since
spawn.freeze_support() independently detects spawned child processes.

Test that freeze_support() does not lock in the default start method,
which would prevent a subsequent set_start_method() call.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
2026-03-15 22:50:19 -07:00
Gregory P. Smith c879b2a7a5 gh-141860: Add on_error= keyword arg to multiprocessing.set_forkserver_preload (GH-141859)
Add a keyword-only `on_error` parameter to `multiprocessing.set_forkserver_preload()`. This allows the user to have exceptions during optional `forkserver` start method module preloading cause the forkserver subprocess to warn (generally to stderr) or exit with an error (preventing use of the forkserver) instead of being silently ignored.

This _also_ fixes an oversight, errors when preloading a `__main__` module are now treated the similarly. Those would always raise unlike other modules in preload, but that had gone unnoticed as up until bug fix PR GH-135295 in 3.14.1 and 3.13.8, the `__main__` module was never actually preloaded.

Based on original work by Nick Neumann @aggieNick02 in GH-99515.
2026-01-18 14:04:18 -08:00
Eddy Mulyono 80284b5c5e gh-80334: fix multiprocessing.freeze_support for other spawn platforms (GH-134462)
Doc/library/multiprocessing.rst: freeze_support: Change to specify spawn method instead of platform
Have multiprocessing.freeze_support() enable on spawn, not just win32.

---------

Co-authored-by: Gregory P. Smith <greg@krypto.org>
2025-05-24 03:50:19 +00:00
Gregory P. Smith b65f2cdfa7 gh-84559: Change the multiprocessing start method default to forkserver (GH-101556)
Change the default multiprocessing start method away from fork to forkserver or spawn on the remaining platforms where it was fork.  See the issue for context.  This makes the default far more thread safe (other than for people spawning threads at import time... - don't do that!).

Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
2024-09-26 16:57:19 -07:00
Victor Stinner 6ae254aaa0 gh-120417: Add #noqa to used imports in the stdlib (#120421)
Tools such as ruff can ignore "imported but unused" warnings if a
line ends with "# noqa: F401". It avoids the temptation to remove
an import which is used effectively.
2024-06-13 16:14:50 +02:00
Gregory P. Smith d4c410f0f9 gh-84559: Remove the new multiprocessing warning, too disruptive. (#101551)
This reverts the core of #100618 while leaving relevant documentation
improvements and minor refactorings in place.
2023-02-03 15:20:46 -08:00
Gregory P. Smith 0ca67e6313 GH-84559: Deprecate fork being the multiprocessing default. (#100618)
This starts the process. Users who don't specify their own start method
and use the default on platforms where it is 'fork' will see a
DeprecationWarning upon multiprocessing.Pool() construction or upon
multiprocessing.Process.start() or concurrent.futures.ProcessPool use.

See the related issue and documentation within this change for details.
2023-02-02 15:50:35 -08:00
Leo Trol 30610d2837 gh-90549: Fix leak of global named resources using multiprocessing spawn (#30617)
Co-authored-by: XD Trol <milestonejxd@gmail.com>
Co-authored-by: Antoine Pitrou <pitrou@free.fr>
2022-06-09 18:55:12 +02:00
idomic db098bc1f0 bpo-39244: multiprocessing return default start method first on macOS (GH-18625) 2020-05-26 17:54:21 +03:00
Victor Stinner 17a5588740 bpo-33725: multiprocessing uses spawn by default on macOS (GH-13603)
On macOS, the multiprocessing module now uses the "spawn" start
method by default.
2019-05-28 16:02:50 +02:00
Thomas Moreau c09a9f56c0 bpo-36888: Add multiprocessing.parent_process() (GH-13247) 2019-05-20 21:37:05 +02:00
Derek B. Kim c40278ef95 Simplify __all__ in multiprocessing (GH-6856) 2018-07-11 19:22:28 +09:00
Jon Dufresne 3972628de3 bpo-30296 Remove unnecessary tuples, lists, sets, and dicts (#1489)
* Replaced list(<generator expression>) with list comprehension
* Replaced dict(<generator expression>) with dict comprehension
* Replaced set(<list literal>) with set literal
* Replaced builtin func(<list comprehension>) with func(<generator
  expression>) when supported (e.g. any(), all(), tuple(), min(), &
  max())
2017-05-18 07:35:54 -07:00
Serhiy Storchaka 5affd23e6f bpo-29762: More use "raise from None". (#569)
This hides unwanted implementation details from tracebacks.
2017-04-05 09:37:24 +03:00
Antoine Pitrou ebb39bcc04 Issue #28779: multiprocessing.set_forkserver_preload() would crash the forkserver process if a preloaded module instantiated some multiprocessing objects such as locks. 2016-12-10 17:16:17 +01:00
Antoine Pitrou cd2a201e5b Issue #28779: multiprocessing.set_forkserver_preload() would crash the forkserver process if a preloaded module instantiated some multiprocessing objects such as locks. 2016-12-10 17:13:16 +01:00
Davin Potts 5458647bb8 Issue #28053: Applying refactorings, docs and other cleanup to follow. 2016-09-09 18:03:10 -05:00
Richard Oudkerk b1694cf588 Issue #18999: Make multiprocessing use context objects.
This allows different parts of a program to use different methods for
starting processes without interfering with each other.
2013-10-16 16:41:56 +01:00