You're going to have to move the discussion to python-dev or the python issue tracker then.
On Fri, Mar 28, 2014 at 4:02 PM, Giampaolo Rodola' <[email protected]>wrote: > > 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 > > -- --Guido van Rossum (python.org/~guido)
