Author aeros
Recipients aeros, asvetlov, primal, yselivanov
Date 2019-11-04.18:58:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1572893915.1.0.404323482763.issue32309@roundup.psfhosted.org>
In-reply-to
Content
> Nice work! This is a great excercise, but we can really just use concurrent.futures.ThreadPool as is. Spawning threads is fast. As I mentioned before all we need to do is to design *our* API to NOT initialize pools in __init__, that's it. The design outlined in https://bugs.python.org/msg355881 would do that.

Thanks, it was quite helpful for better understanding the internals of ThreadPoolExecutor. 

I think that I'm still not understanding something important though. Even if we initialize our ThreadPoolExecutor outside of __init__ (in a start() coroutine method, as your proposing), it seems like the threads will be spawned throughout the lifespan of the threadpool, rather than upon startup since the new threads are spawned in ThreadPoolExecutor *after* executor.submit() is called (up to max_workers) rather than upon initialization. So even if an instance of ThreadPoolExecututor is initialized asynchronously within a start() coroutine method, the individual threads within it won't be spawned at the same time.

That's why I wrote an explicit way of spawning threads in the above example, based on the way that ThreadPoolExecutor spawns threads in _adjust_thread_count(), which is called at the end of submit().
History
Date User Action Args
2019-11-04 18:58:35aerossetrecipients: + aeros, asvetlov, yselivanov, primal
2019-11-04 18:58:35aerossetmessageid: <1572893915.1.0.404323482763.issue32309@roundup.psfhosted.org>
2019-11-04 18:58:35aeroslinkissue32309 messages
2019-11-04 18:58:34aeroscreate