multiprocessing's freeze_support makes freshly-launched subprocesses integrate correctly until the multiprocessing ecosystem even when the main executable is some application binary instead of a Python interpreter. The documentation and code assume that this support is needed only on win32, but it's equally applicable to POSIX systems using the spawn strategy in combination with systems like cx_freeze.

In particular:

1. The special case in context.py's version of freeze_support() for win32 should be removed

2. The semaphore tracker should correctly tickle the freeze support

3. The documentation should be updated to be platform-neutral

Thank you for reporting this. Would you like to submit a PR?

I ran into this issue, and found references to it on StackOverflow [1] and GitHub [2] as well. I found that the problem applies to both the 'spawn' and 'forkserver' start methods on Linux.

I made an attempt to implement dancol's fix above. (1) and (3) are straightforward, but if there's an elegant way to do the "tickle" in (2) I wasn't able to figure it out?

My branch [3] has something that seems to work with the 'spawn' method and cx_Freeze. Perhaps someone could look at that and tell me if I'm on a reasonable track? If so, I can attempt to extend the method to cover 'forkserver' as well.

[1] https://stackoverflow.com/q/47325297/353839

[2] marcelotduarte/cx_Freeze#264

[3] master...bbayles:bpo-32146-freeze_support

I presume it's too late to get my pull request in for 3.7, but perhaps we could get a note in the documentation for this before release?

That could be as simple as:

.. warning::

The ``'spawn'`` and ``'forkserver'`` start methods cannot currently be used with "frozen" executables (i.e., binaries produced by packages like **PyInstaller** and **cx_Freeze**) on Unix. The ``'fork'`` start method does work.

I will make that into a PR if it seems like a good option.

I'm sorry about not seeing your PR before. Would you like to update it against current git master?

(note I'm not thrilled by the use of the "ast" module; I hope we can change the command-line args so that this isn't needed)

New changeset bab4bbb by Victor Stinner (Bo Bayles) in branch 'master':
bpo-32146: Add documentation about frozen executables on Unix (GH-5850)
bab4bbb

New changeset b9cd38f by Miss Islington (bot) in branch '3.7':
bpo-32146: Add documentation about frozen executables on Unix (GH-5850)
b9cd38f

Thanks for the note. I've merged in master and fixed a conflict in the test file.

In an earlier rev I tried to do the argument parsing without ast.literal_eval, but found it awkward to support all the ways [1] can manifest. You might have a better idea?

[1] https://github.com/python/cpython/blob/3.7/Lib/multiprocessing/forkserver.py#L106-L107

The key here would be to replace function execution with module execution and command-line arguments.

So instead of:

python -c 'from multiprocessing.forkserver import main; main(ARG1, ARG2...)'

you would do:

python -m multiprocessing.forkserver ARG1 ARG2 ....

Then it should become easy to extract the concatenated command lines.

(and if that works, please do the same for semaphore_tracker ;-))

I'm currently having difficulty getting either cx_Freeze or PyInstaller to work with Python 3.8, which is hindering testing. I also no longer have easy access to a Windows environment.

If I change the implementation to use -m instead of -c would you be able to test?

@bbayles Hopefully a Windows user could test if you give a step-by-step guide of what to check for.

The documentation still says

Calling freeze_support() has no effect when invoked on any operating system other than Windows.

I'm happy to submit a fix but I'm unsure what to say/write because I'm not familiar with the matter.