Message149996
| Author | neologix |
|---|---|
| Recipients | asksol, brandon-rhodes, cool-RR, dholth, jnoller, neologix, numbernine, pitrou, rcoyner, santoso.wijaya, sbt, vsekhar |
| Date | 2011-12-21.15:04:27 |
| SpamBayes Score | 6.797884e-10 |
| Marked as misclassified | No |
| Message-id | <1324479868.79.0.609367570922.issue8713@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
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? |
|
| History | |||
|---|---|---|---|
| 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 | |