Sample code with multiprocessing freeze_support and set_start_method fails

[RobH123]

Documentation

On Python3.14 page https://docs.python.org/3/library/multiprocessing.html#multiprocessing-programming-forkserver there's an example:

from multiprocessing import Process, freeze_support, set_start_method

def foo():
    print('hello')

if __name__ == '__main__':
    freeze_support()
    set_start_method('spawn')
    p = Process(target=foo)
    p.start()

My code has:

if __name__ == '__main__':
    multiprocessing.freeze_support() # Multiprocessing support for frozen Windows executables
    multiprocessing.set_start_method('fork') # The default was changed on POSIX systems from 'fork' to 'forkserver' in Python3.14

But on Ubuntu 25.10 that causes:

Traceback (most recent call last):
  File "test.py", line 10705, in <module>
    multiprocessing.set_start_method('fork') # The default was changed on POSIX systems from 'fork' to 'forkserver' in Python3.14
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^
  File "/usr/lib/python3.14/multiprocessing/context.py", line 247, in set_start_method
    raise RuntimeError('context has already been set')
RuntimeError: context has already been set

It seems that set_start_method() has to be called BEFORE freeze_support, not AFTER.

[picnixz]

This could be a legitimate bug in freeze_support() though. Does such code also fail on 3.13?

[RobH123]

Sorry, didn't think to test that because I've never had to use set_start_method() before 3.14.

But yes, it gives exactly the same error with 3.13 (and again putting set_start_method() BEFORE freeze_support() fixes it.

[picnixz]

Ok, so the changing the default start method didn't create an undesired side-effect. Thanks for checking this! I'll check tomorrow the content of freeze_support just to be sure but I think this is just a documentation issue (the other occurrences of freeze_support don't use set_start_method so it was probably an oversight). I'll also check if this was always like that or if something changed in Python 3.X < 3.13 (maybe we did change something else which made this example fail)

Thanks for catching this!

[RobH123]

Thanks for all your work.

P.S. I still don't understand why my code below fails with the new 3.14 default forkserver:

  with multiprocessing.Pool( processes=numProcesses ) as pool: # start worker processes
      results = pool.map( self._loadBookMP, self.maximumPossibleFilenameTuples ) # have the pool do our loads
      assert len(results) == len(self.maximumPossibleFilenameTuples)

It seems to not get the (pickled) global context. Is it less efficient to use 'fork' than 'forkserver'? Or is there any simple fix/improvement to that code? (The _loadBookMP function loads and parse a long/complex text file and returns a large dict, so the pickling cost of some globals isn't too bad and it's very advantageous to use all the CPUs for the long, slow load & parse.)

[picnixz]

In general, forkserver is safer than fork but yeah it actually broke code for folks that relied on fork since it could just copy the entire process with fork. I don't know the pickling error you're getting but it's likely because it's no more possible to pickle some names.

A simple way to switch back to the old (but sometimes unsafe) method is to force set_start_method("fork"). Note that while fork may seem to work, you might encounter deadlocks (long story short, threads and forks don't play well). I would suggest you to post on https://discuss.python.org/c/help/7 if you want more help (this repository is only for tracking bugs, sorry)

[xcpky]

I encounter the same issue. So What's the correct way if I want to use fork server and enable freeze support simultaneously for pyinstaller?

mp.set_start_method('forkserver')
mp.freeze_support()

is this order correct?