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-le...@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/FH44JOI73IOCJ42QSI3YFU7S7RDWYYZI/
Code of Conduct: http://python.org/psf/codeofconduct/
