New submission from Andreas van Cranenburgh:
It would be useful if concurrent.futures.ThreadPoolExecutor took an initializer
argument, like multiprocessing.Pool.
This is useful for example to load a large dataset once upon initialization of
each worker process, without have to pass the
Andreas van Cranenburgh added the comment:
Yes I did mean ProcessPoolExecutor, but indeed, it's good to have for threads
as well.
I could try to make a patch if it is likely that it would be accepted.
--
___
Python tracker
<http://bugs.py
Andreas van Cranenburgh added the comment:
Here's a patch. I have added initializer and initargs keywords to both
ThreadPoolExecutor and ProcessPoolExecutor, with the same semantics as
multiprocessing.Pool.
I couldn't figure out what to do if the initializer fails with a
ProcessPo
Andreas van Cranenburgh added the comment:
Here's a version with tests. Detecting an execption in the initializer works
with ProcessPoolExecutor, but not with ThreadPoolExecutor.
--
Added file: http://bugs.python.org/file35181/pool_initializer_tests.
Andreas van Cranenburgh added the comment:
Giampaolo, this patch is for ProcessPoolExecutor as well.
About keyboard interrupts, if my tests are correct, they work
in Python 3.3+ with both multiprocessing and concurrent.futures.
(Although for the latter I have to hit ctrl-c twice
