> 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 <mocra...@gmail.com> wrote: > 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/ >
_______________________________________________ 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/WK5AOBFVWTUHTGGO5HJMUPISTKPABHXG/ Code of Conduct: http://python.org/psf/codeofconduct/
