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 neologix
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.15:00:22
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> 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,

The risk of leak is IMO much greater.
Date User Action Args
2013-10-21 15:00:22neologixsetrecipients: + neologix, lemburg, twouters, georg.brandl, gregory.p.smith, jcea, amaury.forgeotdarc, pitrou, vstinner, christian.heimes, grahamd, Arfrever, asvetlov, sbt, aliles, DLitz
2013-10-21 15:00:22neologixlinkissue16500 messages
2013-10-21 15:00:22neologixcreate