Le Thu, 10 Jan 2013 11:35:29 +0100, Charles-François Natali firstname.lastname@example.org a écrit :
So, I read your e-mail again and I'm wondering if you're making a logic error, or if I'm misunderstanding something:
- first you're talking about duplicate file or socket objects after
*fork()* (which is an issue I agree is quite annoying)
- 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).
Yes. In this specific case, the proper solution is to close the server socket right after fork() in the child process.
We can't do anything about file descriptors inherited upon fork() (and shouldn't do anything of course, except on an individual basis like this socket server example).
Having an official afterfork facility would still help. I currently rely on multiprocessing.util.register_after_fork(), even though it's an undocumented API (and, of course, it works only for those child processes launched by multiprocessing, not other fork() uses).