Pyinstaller multiprocessing name of process is always "MainProcess"

[Indiana3714]

Here's my test code (py 2.7 on Windows):

import multiprocessing

print multiprocessing.current_process().name
print type(multiprocessing.current_process())
print type(multiprocessing.current_process().name)

def main():
    pass

if __name__ == "__main__":
    multiprocessing.freeze_support()
    p = multiprocessing.Process(target=main, name="My Child Process")
    p.start()

Without compiling, the code works fine as it prints out

MainProcess
<class 'multiprocessing.process._MainProcess'>
<type 'str'>
My Child Process
<class 'multiprocessing.process._MainProcess'>
<type 'str'>

After using pyinstaller on it, unfortunately it will always default to "MainProcess". Result as follows:

MainProcess
<class 'multiprocessing.process._MainProcess'>
<type 'str'>
MainProcess
<class 'multiprocessing.process._MainProcess'>
<type 'str'>

[htgoebel]

Are you using --onefile mode? Please try --onedir mode.
This might ne an issue with the freeze_support. Please try Python 3.x

[htgoebel]

Please also state wich exact version of PyInstaller you are using. Please try the current development head.

[Indiana3714]

@htgoebel I'm using pyinstaller 3.4 on python 2.7. Using it in the regular mode with the folder? Not one single file.exe. I tried using it on python 3.6 but it was kind of tricky to have it set to compile under python 3.6 by default instead of 2.7

[Indiana3714]

Please also state wich exact version of PyInstaller you are using. Please try the current development head.

PyInstaller: 3.5.dev0+1844d69f5 version still has the same issue

[htgoebel]

Please try putting multiprocessing.freeze_support() just after the import multiprocesseing

[Indiana3714]

@htgoebel Doesn't work:

MainProcess
<class 'multiprocessing.process.MainProcess'>
<type 'str'>
Traceback (most recent call last):
File "githubexamplefile.py", line 2, in
File "multiprocessing_init.py", line 145, in freeze_support
File "multiprocessing\forking.py", line 337, in freeze_support
File "multiprocessing\forking.py", line 381, in main
File "pickle.py", line 1384, in load
File "pickle.py", line 864, in load
File "pickle.py", line 1096, in load_global
File "pickle.py", line 1132, in find_class
AttributeError: 'module' object has no attribute 'main'
[4684] Failed to execute script githubexamplefile

Press Enter or Esc to close console...

[jordanjuras]

Please try putting multiprocessing.freeze_support() just after the import multiprocesseing

This fixed the described issue for me.

Note: I had put multiprocessing.freeze_support() immediately following the main definition for this python script, but new windows/processes were kicked off one after the next.

[Indiana3714]

Issue still there when I'm using Python 3.7.4 now.

[olbermann]

I had very similar problems and was able to get rid of the AttributeError ... Failed to execute script...
by moving the target function to a different module and importing it into the script.

[Ratgor]

Python 3.5, PyInstaller 3.5
Same issue
Fixed by putting multiprocessing.freeze_support() before the first call of multiprocessing inside a function, not "immediately after" import multiprocessing (attribute error).

[migueldingli1997]

Any progress on this? I'm experiencing this on Mac OS where a new process also named __main__ gets created when I start a new process. In my case the workaround I used is the following, where start() is the rest of my program:

if __name__ == '__main__':
    multiprocessing.freeze_support()
    if 'main_started' not in os.environ:
        os.environ['main_started'] = ''
        start()

[juanzt]

On MacOS Big Sur, fixed as htgoebel suggested:

import multiprocessing
multiprocessing.freeze_support()

It seems critical that freeze_support() is called immediately after the import.

[rokm]

Using multiprocessing.freeze_support() is not a work-around - it is the proper way of making multiprocessing work with frozen applications.

It allows PyInstaller to insert a hook that handles process spawning in the frozen application. This works differently than in unfrozen mode, because there's no python(.exe) executable involved, and so the frozen application's executable needs to handle being ran multiple times with different multiprocessing-specific arguments. The PyInstaller's hook effectively scans sys.argv for multiprocessing-specific arguments and if present, handles the further execution - so the code in those auxiliary and worker processes doesn't go beyond the multiprocessing.freeze_support() call.

This is why omitting this call results in infinite process spawning loop; as each spawned auxiliary or worker process thinks it is main process, and executes main code, and therefore eventually tries to use multiprocessing again, which results in another set of auxiliary and worker processes being spawned...

And this is why you should make the call to multiprocessing.freeze_support() "as soon as possible":

• before you run any "main" code, such as command-line parsing (because you don't want to handle command line from auxiliary processes) or UI construction (because you don't want that in auxiliary and your worker processes)
• after any structures (classes, functions) that are used in your processes are defined (as calling it before will result in worker processes lacking those definitions, leading to error).