Kyle Stanley <aeros...@gmail.com> added the comment:
> Agreed, and that is precisely what I suggested in my previous comment. The > attached PR already deals with the executor-specific part of the wait, but it > would be straightforward to have it also affect the executor to create daemon > threads, and the flag moved to the constructor. Ah, I see. That should be fine then, but I would like to wait on additional feedback to make sure that re-adding daemon threads (even as a opt-in flag) is something that we want to do. I think you do have a good point regarding the practical utility in situations where it may not be feasible to programmatically prevent a thread from hanging indefinitely, but the main questions are: Is it something that ought to be provided by ThreadPoolExecutor? If so, is this the best way to implement it? > It is quite easy to check that a hanging thread (emulated by a simple sleep) > is not joined by the executor with the appropriate flag set. That would certainly be part of it, but we also have to verify a few other things (this is off the top of my head, so I'm likely missing some points): 1) All of the threads are created as daemon threads, instead of regular threads when the flag is set (easy) 2) The hanging thread itself was able to finalize properly (without any leaked references or resource issues) 3) The rest of the executor resources were able to finalize properly, despite the hanging thread 4) The interpreter was able to finalize properly, despite the hanging thread It's not so much writing the tests that will be especially involved, it's more so the time investment required to get them all to pass. Which could potentially be on the first try, or it could take many different implementations until it works across supported platforms. In my experience so far from working with the executors, it's more likely to be the latter. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue36780> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
