2. the solution you're proposing doesn't close the file descriptors after fork() but after *exec()*.
Exact. My PEP cannot solve all issues :-) I will update it to make it more explicit.
Having an official afterfork facility would still help.
Yes. IMO it is a different topic: you can also call exec() without calling fork() first ;-) Victor 2013/1/10 Antoine Pitrou <solipsis@pitrou.net>:
Le Thu, 10 Jan 2013 11:35:29 +0100, Charles-François Natali <neologix@free.fr> 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:
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).
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).
Regards
Antoine.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com