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 <CAH_1eM1_r3fHQZrPMd-E8K4WRFfALn9pi9LT5XW4Ja4iUK1uHA@mail.gmail.com>
In-reply-to <1382366504.66.0.993376755414.issue16500@psf.upfronthosting.co.za>
Content
> 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.
History
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