Message359960
> I think this should be fixed like ThreadPoolExecutor.
Are there are any downsides or complications with changing this behavior for ProcessPoolExecutor to consider, such as what I mentioned above? From my understanding, there would be a performance penalty associated with spawning the processes on-demand as opposed to the current behavior of spawning *max_workers* processes at the same time, and using each of them as needed.
Also, I think it's worth considering the following: do the same arguments for changing the behavior for ThreadPoolExecutor also apply to ProcessPoolExecutor? Although they share the same executor API, they have rather different use cases.
That being said, if it's decided that we do want to make this behavior consistent with ThreadPoolExecutor, I would be willing to look into implementing it. I just want to make sure that it's carefully considered first. |
|
Date |
User |
Action |
Args |
2020-01-14 09:43:18 | aeros | set | recipients:
+ aeros, bquinlan, pitrou, methane, yus2047889 |
2020-01-14 09:43:18 | aeros | set | messageid: <1578994998.22.0.514475272015.issue39207@roundup.psfhosted.org> |
2020-01-14 09:43:18 | aeros | link | issue39207 messages |
2020-01-14 09:43:17 | aeros | create | |
|