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.
(cherry picked from commit ee5318025b)
Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
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.
---------
(cherry picked from commit 80284b5c5e)
Co-authored-by: Eddy Mulyono <eddymul@gmail.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
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.
