Le Thu, 10 Jan 2013 11:35:29 +0100, Charles-François Natali <neologix at 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4