Okay, I don’t really have a reason to get into any bikeshedding of the API presented, and the general idea is one that seems good to me, whatever specific form it takes shouldn’t be an issue, I also can’t think of a strong reason why this would prompt the full atexit.register_early solution over this, even if I’m personally interested in a better multi-phase shutdown overall.
I have two followup questions, but the answers won’t be ones that would change my opinion of if the feature should exist; This seems like a good way to reduce reliance on daemon threads to me irrespective of the answers to them.
- Will threads have their termination callbacks invoked in a deterministic reliable order? If not, is it worth a simple shuffle to ensure people don’t end up relying on the implementation ordering and add their own synchronization to shutdown if necessary?
- Would it also be worth an API in
atexitthat can register shutdown that’s specific to when in an interactive session and is a noop otherwise to help cover any non-threading cases, or do you think that the non-threading cases are suitably covered byatexitwithout this?