This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author josh.r
Recipients aeros, jack__d, janfrederik.konopka, josh.r, pitrou, tomMoral
Date 2022-04-06.15:13:34
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
I think this is causing a regression for code that explicitly desires the ThreadPoolExecutor to go away abruptly when all other non-daemon threads complete (by choosing not to use a with statement, and if shutdown is called, calling it with wait=False, or even with those conditions, by creating it from a daemon thread of its own).

It doesn't seem like it's necessary, since the motivation was "subinterpreters forbid daemon threads" and the same release that contained this change (3.9.0alpha6) also contained #40234's change that backed out the change that forbade spawning daemon threads in subinterpreters (because they now support them by default). If the conflicts with some uses of subinterpreters that make it necessary to use non-daemon threads, could that be made a configurable option (ideally defaulting to the pre-3.9 choice to use daemon threads)?
Date User Action Args
2022-04-06 15:15:35josh.runlinkissue39812 messages
2022-04-06 15:13:34josh.rsetrecipients: + josh.r, pitrou, tomMoral, aeros, janfrederik.konopka, jack__d
2022-04-06 15:13:34josh.rsetmessageid: <>
2022-04-06 15:13:34josh.rlinkissue39812 messages
2022-04-06 15:13:34josh.rcreate