Charles-François Natali <neolo...@free.fr> added the comment: 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? ---------- nosy: +neologix, pitrou _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8713> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
