gh-135726: multiprocessing.freeze_support no longer sets the start method globally.

[aisk]

• Issue: Regression in multiprocessing.set_start_method introduced in Python 3.13.4 #135726

[gpshead]

Could you come up with a meaningful regression test for this?

[gpshead]

Rather than adding this method to DefaultContext, which complicates the picture of which one is called when and why two are defined in the heirarchy, perhaps edit the one in BaseContext to something like this:

diff --git a/Lib/multiprocessing/context.py b/Lib/multiprocessing/context.py
index 051d567d457..2d5c9a1d3dd 100644
--- a/Lib/multiprocessing/context.py
+++ b/Lib/multiprocessing/context.py
@@ -145,7 +145,11 @@ def freeze_support(self):
         '''Check whether this is a fake forked process in a frozen executable.
         If so then run code specified by commandline and exit.
         '''
-        if self.get_start_method() == 'spawn' and getattr(sys, 'frozen', False):
+        # GH-135726: allow_none=True prevents this "get" call from setting the
+        # default context as the selected one as a side-effect.
+        if (getattr(sys, 'frozen', False) and
+            isinstance(self.get_start_method(allow_none=True)
+                       or _default_context, SpawnContext)):
             from .spawn import freeze_support
             freeze_support()
 

(untested - I'm just trying to reason though the logic)

[aisk]

Thank you for the review, updated!

[marcelotduarte]

@aisk This second commit will not break the patches I already have in use in cx_Freeze, because I monkeypatched freeze_support. And it does not interfere with the start method in Python (since it is not frozen). On Windows, this should work as it was before the PR that caused the regression. On Linux and macOS, I will continue monkeypatching until the gh-76327 is applied.