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] https://github.com/anthony-tuininga/cx_Freeze/issues/264

[3] bpo-32146-freeze_support">https://github.com/python/cpython/compare/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.