Repository navigation
Starting a Process from "spawn" context has side effect of fixing start method to "fork" on Linux #109263
Description
Bug report
Bug description:
Hello.
I observed that using a "spawn" context on Linux set the global start method to "fork", which is quite surprising to me:
import multiprocessing
def worker():
pass
if __name__ == "__main__":
spawn_context = multiprocessing.get_context("spawn")
process = spawn_context.Process(target=worker)
print("Start method before:", multiprocessing.get_start_method(allow_none=True)) # None
process.start()
process.join()
print("Start method after:", multiprocessing.get_start_method(allow_none=True)) # "fork"
multiprocessing.set_start_method("spawn") # RuntimeError: context has already been setOne of the reasons for using get_context() is to prevent alterations to global state, as explicitly stated in the documentation.:
A library which wants to use a particular start method should probably use
get_context()to avoid interfering with the choice of the library user.
I suspect the current behavior could potentially be a bug for the following reasons:
- It's unexpected to encounter
"fork"as the global start method when employing a"spawn"context. - This deviates from the documentation's assertion that using
get_context()will not interfere with the user's choice, as it effectively prevents subsequent use ofset_start_method().
If this behavior is intentional, I would like to suggest documenting this edge case for clarity.
CPython versions tested on:
3.11, 3.12
Operating systems tested on:
Linux
Linked PRs
- gh-109263: Start process from spawn context in multiprocessing no longer have side effect #135813
- [3.14] gh-109263: Start process from spawn context in multiprocessing no longer have side effect (GH-135813) #143115
- [3.13] gh-109263: Start process from spawn context in multiprocessing no longer have side effect (GH-135813) #143116
Activity
gpshead commentedon Sep 11, 2023
semi-related your other #109070 issue. 100% agreed that these multiprocessing APIs are not well behaved.
aisk commentedon Jun 22, 2025
This is caused by the fact that the
Popenimplementation for the spawn and forkserver fetches thestart_methodusingget_start_method(allow_none=False)in the main process and passes and set it to the child processes. However,get_start_method(allow_none=False)will also set the global start method using the default implementation.We can simply change
allow_noneto True, because in the child processes, the implementation can handle the case wherestart_methodis None.gh-109263: Start process from spawn context in multiprocessing no lon…
pythongh-109263: Start process from spawn context in multiprocessing …
pythongh-109263: Start process from spawn context in multiprocessing …
gpshead commentedon Dec 24, 2025
Thanks for the fix! merged & backports set to merge. We've recently started documenting this better, you'll find the current multiprocessing docs full of "If the global start method is not set and allow_none is False, the global start method is set to the default," with a link to the section about this gross global context state machine.
[3.13] gh-109263: Start process from spawn context in multiprocessing…
[3.14] gh-109263: Start process from spawn context in multiprocessing…