It would seems reasonable to have a separate _daemon_thread_queues dict (in contrast to _threads_queues) that would not get joined upon exit. A "daemon" (or any better name) parameter of ThreadPoolExecutor initialisation would allow to let it add its workers in this dict rather than the default one.
We're currently looking into adjusting the current Executor implementation
(for both TPE and PPE) to not use daemon threads at all for subinterpreter
compatibility, see https://bugs.python.org/issue39812. Instead of using an
atexit handler, there's some consideration for using a similar
threading-specific "exit handler". Instead of being upon program exit,
registered functions would be called just before all of the non-daemon
threads are joined in `threading._shutdown()`.
As a result, I suspect that we are unlikely to implement something like the
above. But, as a convenient side effect, it should somewhat address the
current potentially surprising behavior.
(Note that this is currently in early draft stages, so it could end up
being entirely different)
On Mon, Mar 9, 2020 at 5:39 PM Remy NOEL
I ran into a problem which, according to a google search is not that uncommon: concurrent.futures ThreadPoolExecutor, installs an exit handler preventing program exit if any of the jobs it is running is blocked. (Which might be a surprising behaviour to someone using those).
It is possible to workaround this problem by either unregistering the exit handler concurrent.futures.thread._python_exit or by subclassing the threadpoolExecutor and overriding the _adjust_thread_count method with one that does not register its threads queues.
Both seems kinda ugly though. It would seems reasonable to have a separate _daemon_thread_queues dict (in contrast to _threads_queues) that would not get joined upon exit. A "daemon" (or any better name) parameter of ThreadPoolExecutor initialisation would allow to let it add its workers in this dict rather than the default one.
Does this seems feasible ?
Thanks !
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FH44JO... Code of Conduct: http://python.org/psf/codeofconduct/