This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pitrou
Recipients Arfrever, DLitz, aliles, amaury.forgeotdarc, asvetlov, christian.heimes, georg.brandl, grahamd, gregory.p.smith, jcea, lemburg, neologix, pitrou, sbt, twouters, vstinner
Date 2013-10-21.18:50:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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,
> 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.
Date User Action Args
2013-10-21 18:50:12pitrousetrecipients: + pitrou, lemburg, twouters, georg.brandl, gregory.p.smith, jcea, amaury.forgeotdarc, vstinner, christian.heimes, grahamd, Arfrever, asvetlov, neologix, sbt, aliles, DLitz
2013-10-21 18:50:12pitrousetmessageid: <>
2013-10-21 18:50:12pitroulinkissue16500 messages
2013-10-21 18:50:12pitroucreate