Charles-François Natali added the comment: > Richard Oudkerk added the comment: > >> - now that FDs are non-inheritable by default, fork locks around >> subprocess and multiprocessing shouldn't be necessary anymore? What >> other use cases does the fork-lock have? > > CLOEXEC fds will still be inherited by forked children.
Hum, right, I was thinking only about subprocess-created children (where an exec follows immediately). >> - the current implementation keeps hard-references to the functions >> passed: so if one isn't careful, you can end up easily with a lot of >> objects kept alive just because of those references, which can be a >> problem > > True, but you could make the same complaint about atexit.register(). Yeah, but atexit is usually used for process-lifetime resources (I mean, there's 'exit' in the name). 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. ---------- _______________________________________ 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
