Author sbt
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.14:41:44
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1382366504.66.0.993376755414.issue16500@psf.upfronthosting.co.za>
In-reply-to
Content
> - 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.

> - 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().

One can fairly easily create something like weakref.finalize which uses atfork but is smart about not creating hard refs.
History
Date User Action Args
2013-10-21 14:41:44sbtsetrecipients: + sbt, lemburg, twouters, georg.brandl, gregory.p.smith, jcea, amaury.forgeotdarc, pitrou, vstinner, christian.heimes, grahamd, Arfrever, asvetlov, neologix, aliles, DLitz
2013-10-21 14:41:44sbtsetmessageid: <1382366504.66.0.993376755414.issue16500@psf.upfronthosting.co.za>
2013-10-21 14:41:44sbtlinkissue16500 messages
2013-10-21 14:41:44sbtcreate