Message149996
Thanks for the patch sbt.
I think this is indeed useful, but I'm tempted to go further and say we should make this the default - and only - behavior. This will probably break existing code that accidentaly relied the fact that the implementation uses a bare fork(), but i'd say it's worth it:
- it's cleaner
- it will make it possible to remove all the ad-hoc handlers called after fork()
- it will remove the only place in the whole stdlib where fork() isn't followed by exec(): people who get bitten by issue #6721 will thus only be people calling explicitely fork(), in which case they're the sole responsibles for their misery ;-)
Another - although less common - advantage over the current implementation is that now one can run out of memory pretty easily if the operating system doesn't do overcommitting if you work with a large dataset. If fork() is followed by an exec, no problem.
Thoughts? |
|
Date |
User |
Action |
Args |
2011-12-21 15:04:28 | neologix | set | recipients:
+ neologix, pitrou, jnoller, rcoyner, asksol, cool-RR, dholth, brandon-rhodes, santoso.wijaya, sbt, numbernine, vsekhar |
2011-12-21 15:04:28 | neologix | set | messageid: <1324479868.79.0.609367570922.issue8713@psf.upfronthosting.co.za> |
2011-12-21 15:04:28 | neologix | link | issue8713 messages |
2011-12-21 15:04:27 | neologix | create | |
|