A pyinstaller 3.0 frozen .exe Python 2.7.10 program under Windows 7 that uses a multiprocessing.Queue to send things to a multiprocessing.Process leads to the process getting access-is-denied exceptions on every q.get() call.

And, when the program can't exit. Or leaves a dangling process for every Process.

An unsatisfying fix for this is to put the following code somewhere in the program:

"""
    Do what must be done to make multiprocessing work in .exe files.

    This involves monkey patching multiprocessing.forking under Windows
    so when the a program using a multiprocessing.Process exits,
    there won't be processes left running.

    Hint from   http://stackoverflow.com/questions/33764448/pathos-multiprocessing-pipe-and-queue-on-windows

    .           The bottom line is we get "access is denied" when trying
    .           to get from the multiprocessing.Queue when we're an .exe file.

    .           So, in multiprocessing.forking.duplicate(),
    .           we change 'inheritable' to default to True
    .           from the normal code's False.

"""

import  sys
import  multiprocessing
import  multiprocessing.forking


#
#
#
#
def duplicate(handle, target_process = None, inheritable = True) :
    return(multiprocessing.forking.kludge_to_fix_dangling_processes(handle, target_process, inheritable))

if  (not hasattr(multiprocessing.forking, 'kludge_to_fix_dangling_processes')) and (sys.platform == 'win32') :
    multiprocessing.forking.kludge_to_fix_dangling_processes    = multiprocessing.forking.duplicate
    multiprocessing.forking.duplicate                           = duplicate

Using tools like pyinstaller (and other competing frozen-exe-creating tools) unfortunately complicates things for multiprocessing to understand the environment it's now in.  It is unclear from this description whether this should be regarded as an issue to be addressed in pyinstaller or in multiprocessing itself.  Any further information along these lines would be much appreciated.

Sorry I can't help more than provide a test environment for any fix. I just plucked the "fix" from StackOverflow and it fixed the Q problem on my machine.

It appears, at the least, the multiprocessing code should probably not rely on the default value for the 'inheritable' argument. That argument does sound like one that might be different in the usual case for Win32 and Unix, just because.

No activity since 2016 and Davin considers that we lack information to debug this issue, so I close this issue as out of date.