Richard Oudkerk added the comment: > A use case for not using fork() is when your parent process opens some > system resources of some sort (for example a listening TCP socket). The > child will then inherit those resources, which can have all kinds of > unforeseen and troublesome consequences (for example that listening TCP > socket will be left open in the child when it is closed in the parent, > and so trying to bind() to the same port again will fail). > > Generally, I think having an option for zero-sharing spawning of > processes would help code quality.
The patch as it stands still depends on fd inheritance, so you would need to use FD_CLOEXEC on your listening socket. But yes, it should be possible to use the closefds feature of _posixsubprocess. BTW, I also have working code (which passes the unittests) that starts a helper process at the beginning of the program and which will fork processes on behalf of the other processes. This also solves the issue of unintended inheritance of resources (and the mixing of fork with threads) but is as fast as doing normal forks. ---------- _______________________________________ 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
