> I don't think there's much ThreadPoolExecutor can do.  If you drop the references to the threads, they still exist and they still be waited upon at interpreter exit.
> 
> The solution is for you to avoid having hanging threads.  In the particular case of TCP connections, I'd recommend using a dedicated framework such as asyncio (or Twisted, Tornado, etc.) instead of home-baked networking code.

As far as I'm aware, I don't think there's a _safe_ way to force a hanging thread to immediately exit without causing resource-related problems (an unsafe way would be something like releasing the internal thread state lock). But in general, I think that hanging threads indicate a fundamental issue in the implementation of the function the thread is targeting. For any operation that can potentially stall or run indefinitely, there should be some form of fail safe or timeout in place to break out of it. So I agree with Antoine that it's ultimately the responsibility of the thread itself to not hang. There's not much of anything that ThreadPoolExecutor can safely do to resolve a hanging thread.

> Also, note that Python sockets have a feature called *timeouts*.

There's also of course timeouts implemented at a higher level in many networking frameworks, if the developer doesn't want to do so at the socket level. For example, see asyncio.wait_for(): https://docs.python.org/3/library/asyncio-task.html#asyncio.wait_for.

> These threads were daemon threads in 3.8, so your patch indeed works there, but we've made them non-daemon in 3.9, for two reasons:
1) daemon threads are fragile and can crash the interpreter at shutdown
2) they are not supported on subinterpreters

Just to briefly clarify on (2), Victor recently opened a PR to revert daemon threads being entirely unsupported in subinterpreters: PR-19456. From reading over the attached bpo issue, it looks like the plan is to deprecate daemon threads in subinterpreters, but to not immediately drop support because users of mod_wsgi and various monitoring tools were reliant upon it (through the C-API).

It seems like the current plan is for it to undergo a deprecation process. Either way though, I still think the change to make executors no longer reliant upon daemon threads was a significant stability improvement and will mean we don't have to make the change later when they are fully unsupported in subinterpreters.