Antoine Pitrou added the comment: > One of the main use cases for atfork hooks would be the numerous stdlib objects which have locks (or locks themselves): most of such objects have arbitrary lifetimes (e.g. logging, events, open files, etc). > The risk of leak is IMO much greater.
Well it is customary for callback-based APIs to hold strong references to their callbacks. If a library wants to avoid leaks, it should register a single callback which will then walk the current "live" resources and protect them. (i.e. the resource lifetime issue should be solved by library or application code, not by the atfork module) By the way, +0 to raising and aborting the fork when there's an exception. The only annoyance I can think about is a buggy library which would prevent the user from forking. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue16500> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
