On Wed, Mar 26, 2014 at 7:35 PM, Guido van Rossum <[email protected]> wrote:
> Another thing to investigate might be how the executor creates the > processes, and if anything happens to signals there. After some further digging this seems to be related with the problem at hand. According to this: http://noswap.com/blog/python-multiprocessing-keyboardinterrupt ...it appears a feasible solution is to prevent workers to ever receive KeyboardInterrupt and have the main process shutdown the pool via pool.terminate() and finally pool.join(). Unfortunately concurrent.futures.ProcessPoolExecutor does not expose all the necessary bits to do that (multiprocessing.Pool(initializer=...) argument and terminate() method). I also suspect that in order to emulate the suggested solution the underlying Process instance should be daemonized, similarly to what multiprocessing.Pool does: http://hg.python.org/cpython/file/3567d7ebd382/Lib/multiprocessing/pool.py#l222 I wonder whether concurrent.futures.ProcessPoolExecutor would be better off exposing more APIs in order to facilitate tasks like these. -- Giampaolo - http://grodola.blogspot.com
