Some more investigation, it seems that the alternate `Queue` fix is a non-starter. From my investigation it seems that the ProcessPoolExecutor is assuming that multiprocess.Queue is gauranteed delivery, and it isn't (because of the pickling). So the issue is that the worker process drops the message if its interrupted while unpickling and the Pool class has no idea-- and assumes that the job is still running. With that being said it seems like my attached patch is probably the most reasonable fix without a major rework of how the ProcessPoolExecutor works.