On Wed, Mar 11, 2020 at 3:20 AM Kyle Stanley aeros167@gmail.com wrote:
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.
We could however easily detect this case: we just need to check current_thread().daemon at submit against existing worker threads.
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.
I completely agree (even more so that i already ran into some undying daemon threads): This should be set up from the very start. Sadly, It is very hard to get rid of them when an entire existing codebase rely on those for exit :/ .
Anyway, thanks for the information and advices !