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>
This commit is contained in:
Gregory P. Smith 2024-09-26 16:57:19 -07:00 committed by GitHub
parent 83e5dc0f4d
commit b65f2cdfa7
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
7 changed files with 75 additions and 33 deletions

View file

@ -286,14 +286,6 @@ to a :class:`ProcessPoolExecutor` will result in deadlock.
Added the *initializer* and *initargs* arguments.
.. note::
The default :mod:`multiprocessing` start method
(see :ref:`multiprocessing-start-methods`) will change away from
*fork* in Python 3.14. Code that requires *fork* be used for their
:class:`ProcessPoolExecutor` should explicitly specify that by
passing a ``mp_context=multiprocessing.get_context("fork")``
parameter.
.. versionchanged:: 3.11
The *max_tasks_per_child* argument was added to allow users to
control the lifetime of workers in the pool.
@ -310,6 +302,12 @@ to a :class:`ProcessPoolExecutor` will result in deadlock.
*max_workers* uses :func:`os.process_cpu_count` by default, instead of
:func:`os.cpu_count`.
.. versionchanged:: 3.14
The default process start method (see
:ref:`multiprocessing-start-methods`) changed away from *fork*. If you
require the *fork* start method for :class:`ProcessPoolExecutor` you must
explicitly pass ``mp_context=multiprocessing.get_context("fork")``.
.. _processpoolexecutor-example:
ProcessPoolExecutor Example

View file

@ -124,11 +124,11 @@ to start a process. These *start methods* are
inherited by the child process. Note that safely forking a
multithreaded process is problematic.
Available on POSIX systems. Currently the default on POSIX except macOS.
Available on POSIX systems.
.. note::
The default start method will change away from *fork* in Python 3.14.
Code that requires *fork* should explicitly specify that via
.. versionchanged:: 3.14
This is no longer the default start method on any platform.
Code that requires *fork* must explicitly specify that via
:func:`get_context` or :func:`set_start_method`.
.. versionchanged:: 3.12
@ -146,9 +146,11 @@ to start a process. These *start methods* are
side-effect so it is generally safe for it to use :func:`os.fork`.
No unnecessary resources are inherited.
Available on POSIX platforms which support passing file descriptors
over Unix pipes such as Linux.
Available on POSIX platforms which support passing file descriptors over
Unix pipes such as Linux. The default on those.
.. versionchanged:: 3.14
This became the default start method on POSIX platforms.
.. versionchanged:: 3.4
*spawn* added on all POSIX platforms, and *forkserver* added for
@ -162,6 +164,13 @@ to start a process. These *start methods* are
method should be considered unsafe as it can lead to crashes of the
subprocess as macOS system libraries may start threads. See :issue:`33725`.
.. versionchanged:: 3.14
On POSIX platforms the default start method was changed from *fork* to
*forkserver* to retain the performance but avoid common multithreaded
process incompatibilities. See :gh:`84559`.
On POSIX using the *spawn* or *forkserver* start methods will also
start a *resource tracker* process which tracks the unlinked named
system resources (such as named semaphores or