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 josh.r
Recipients Matt Spitz, josh.r, torsten
Date 2016-05-31.19:58:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1464724711.06.0.742073044147.issue24882@psf.upfronthosting.co.za>
In-reply-to
Content
Is there a good reason to worry about overeager worker spawning? ProcessPoolExecutor spawns all workers when the first work item is submitted ( https://hg.python.org/cpython/file/3.4/Lib/concurrent/futures/process.py#l361 ), only ThreadPoolExecutor even makes an effort to limit the number of threads spawned. Threads are typically more lightweight than processes, and with the recent GIL improvements, the CPython specific costs associated with threads (particularly threads that are just sitting around waiting on a lock) are fairly minimal.

It just seems like if eager process spawning isn't a problem, neither is (cheaper) eager thread spawning.
History
Date User Action Args
2016-05-31 19:58:31josh.rsetrecipients: + josh.r, torsten, Matt Spitz
2016-05-31 19:58:31josh.rsetmessageid: <1464724711.06.0.742073044147.issue24882@psf.upfronthosting.co.za>
2016-05-31 19:58:31josh.rlinkissue24882 messages
2016-05-31 19:58:30josh.rcreate