iunknwn <sz2...@gmail.com> added the comment:
I feel like there are two reasonable options here:
1) We can implement a thread pool with basic resource tracking. This means idle
threads get recycled, and threads that have been sitting idle for a while are
terminated as demand dro
iunknwn <sz2...@gmail.com> added the comment:
Done - as recommend, I've opened a new PR that changes the behavior to spawn
all worker threads when the executor is created. This eliminates all the thread
logic from the submit function.
--
___
Change by iunknwn <sz2...@gmail.com>:
--
pull_requests: +6224
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24882>
___
__
iunknwn <sz2...@gmail.com> added the comment:
Alright - I'll put together another patch that removes the logic, and spins up
all threads during initialization.
Do you want me to create a completely new PR, or just update my existi
iunknwn <sz2...@gmail.com> added the comment:
The existing behavior seems strange (and isn't well documented). The code had a
TODO comment from bquinlan to implement idle thread recycling, so that was why
I made the change.
That said, if threads are cheap, why not just create all th
iunknwn <sz2...@gmail.com> added the comment:
I've submitted a PR that should resolve this - it uses a simple atomic counter
to ensure new threads are not created if existing threads are idle.
One concern I do have - while writing the patch, I noticed the existing submit
method (specif
Change by iunknwn <sz2...@gmail.com>:
--
nosy: +iunknwn
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue24882>
___
___
Python
