Ben Darnell <ben.darn...@gmail.com> added the comment:
> IMO, a better practice would be providing those potentially infinite running > tasks a direct method of escape and invoking it before calling > executor.shutdown(), it would be a more reliable approach. Agreed, but the problem is that I'm in a library (so I don't control the main module), and the library's interface does not mandate any sort of explicit shutdown method. There is a shutdown method, but almost no one calls it, and it's never caused a problem until Python 3.9 changed things so it deadlocks. > My only concern is that it might be a potential foot-gun. If the user submits > an atexit hook that deadlocks, it might prevent threads from shutting down > safely prior to interpreter finalization. Yes, and that is exactly the problem. concurrent.futures submits an atexit hook whose behavior depends on application code, and through that I have inadvertently caused a deadlock. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue41962> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
