[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor

Brian Quinlan added the comment: So you actually use the result of ex.submit i.e. use the resulting future? If you don't then it might be easier to just create your own thread. -- ___ Python tracker ___

[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor

Luca Falavigna added the comment: There is indeed little benefit in freeing up resources left open by a unused thread, but it could be worth closing it for specific needs (e.g. thread processes sensible information) or in embedded systems with very low resources. -- __

[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor

Changes by Ned Deily : -- nosy: +bquinlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor

Josh Rosenberg added the comment: Can you explain what benefit this would provide? Forcing the thread to exit gets you relatively little benefit. If it's an infrequently used executor, I suppose you avoid the cost of leaving worker threads blocked waiting for work, but that cost is tiny, and y

[issue22361] Ability to join() threads in concurrent.futures.ThreadPoolExecutor

New submission from Luca Falavigna: I have a program which waits for external events (mostly pyinotify events), and when events occur a new worker is created using concurrent.futures.ThreadPoolExecutor. The following snippet represents shortly what my program does: from time import sleep from