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 set

One 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:

1. It's unexpected to encounter "fork" as the global start method when employing a "spawn" context.
2. 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 of set_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