This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aeros
Recipients aeros, bquinlan, methane, pitrou, yus2047889
Date 2020-01-14.09:43:17
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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:18aerossetrecipients: + aeros, bquinlan, pitrou, methane, yus2047889
2020-01-14 09:43:18aerossetmessageid: <>
2020-01-14 09:43:18aeroslinkissue39207 messages
2020-01-14 09:43:17aeroscreate