IIUC, I don't think there's a way that we could reasonably support stability for provide any guarantees for spawning or interacting with the Executors from a daemon thread. It might even be worth considering to explicitly warn or prevent that in some capacity.

Antoine Pitrou wrote:

> Daemon threads are already a bad idea, actually.  It is really worth

> the effort to ensure your threads exit cleanly rather than expect the

> interpreter to kill them at shutdown.

Agreed. Furthermore, if there's a thread in a program that can potentially hang indefinitely, converting them into daemon threads (allowing it to be killed on interpreter shutdown) just obscures the problem in most cases, IMO. There should be some consideration placed into preventing a thread from hanging indefinitely in the first place, such as with timeouts or some form of outside signaling (such as threading.Event).

That's not to say that daemon threads aren't sometimes useful. Essentially, if you're okay with the thread being abruptly killed without allowing it's resources to be cleaned up gracefully, making it a daemon thread shouldn't be a significant issue. But, the core problem here is that ThreadPoolExecutor is an example of a resource that should be cleaned up gracefully, so spawning it in a daemon thread or trying to interact with it through one can interfere with that process.