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 ?