iunknwn 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 drops, so resources can be
iunknwn 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.
--
___
Python tracker
&
Change by iunknwn :
--
pull_requests: +6224
___
Python tracker
<https://bugs.python.org/issue24882>
___
___
Python-bugs-list mailing list
Unsubscribe:
iunknwn 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 existing one?
--
___
Python tr
iunknwn 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 the work threa
iunknwn 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 (specificall
Change by iunknwn :
--
nosy: +iunknwn
___
Python tracker
<https://bugs.python.org/issue24882>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.pyth
