Message200779
| 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:19 | neologix | set | recipients:
+ 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:19 | neologix | link | issue16500 messages |
| 2013年10月21日 13:48:18 | neologix | create |
|