Le Wed, 9 Jan 2013 13:48:49 +0100, Victor Stinner firstname.lastname@example.org a écrit :
Until recently (2011-05-24, issue #5715), the listening socket was not closed after fork for the ForkingMixIn flavor. This caused two issues: it's a security leak, and it causes "address already in use" error if the server is restarted (see the first message of #12107 for an example with Django).
I wrote a patch attached to the issue #12107 which adds a flag to enable or disable close-on-exec, I chose to enable the flag by default: http://bugs.python.org/issue12107
So, I read your e-mail again and I'm wondering if you're making a logic error, or if I'm misunderstanding something:
1. first you're talking about duplicate file or socket objects after *fork()* (which is an issue I agree is quite annoying)
2. the solution you're proposing doesn't close the file descriptors after fork() but after *exec()*.
Basically the solution doesn't address the problem. Many fork() calls aren't followed by an exec() call (multiprocessing comes to mind).
On the other hand, the one widespread user of exec() after fork() in the stdlib, namely subprocess, *already* closes file descriptors by default, so the exec() issue doesn't really exist anymore for us (or is at least quite exotic).