Kyle Stanley <aeros...@gmail.com> added the comment:
> 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(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32309> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
