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.13:48:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM2NtrE3Ybb9AKr2Oy-kQ==_EgfSP0+KrGacpXfejQRS1Q@mail.gmail.com>
In-reply-to <1382360532.86.0.601550711219.issue16500@psf.upfronthosting.co.za>
Content
I have a couple random remarks:
- 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?
- 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
- also, since we're not sure about the API, and it's mostly intended
to be used for the interpreter/stdlib, how about making it private for
now, or at least "provisional' (I think that's the term)?
- I'm also +1 on exceptions in prepare hook preventing fork, but we'll
need to play a bit with actual fork hooks to see if that's a
reasonable approach
History
Date User Action Args
2013-10-21 13:48:19neologixsetrecipients: + neologix, lemburg, twouters, georg.brandl, gregory.p.smith, jcea, amaury.forgeotdarc, pitrou, vstinner, christian.heimes, grahamd, Arfrever, asvetlov, sbt, aliles, DLitz
2013-10-21 13:48:19neologixlinkissue16500 messages
2013-10-21 13:48:18neologixcreate