[Python-Dev] fork or exec? (original) (raw)
Victor Stinner victor.stinner at gmail.com
Sat Jan 12 21:29:18 CET 2013
- Previous message: [Python-Dev] fork or exec?
- Next message: [Python-Dev] fork or exec?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
2013/1/11 Ben Leslie <benno at benno.id.au>:
Python is not UNIX, but I think if you are directly using the POSIX interfaces they should work (more or less) the same way the would if you were writing a C program. (Some of us still use Python to prototype things that will later be converted to C!).
I completed the PEP to list advantages and drawbacks of the different alternatives. I moved the PEP to the PEP repository because I now consider it complete enough (for a first draft!):
http://www.python.org/dev/peps/pep-0433/
I see 3 major alternatives:
(a) add cloexec=False argument to some functions
http://www.python.org/dev/peps/pep-0433/#proposition Drawbacks: http://www.python.org/dev/peps/pep-0433/#scope
(b) always set close-on-exec flag and add cloexec=True argument to some functions (to be able to disable it)
http://www.python.org/dev/peps/pep-0433/#always-set-close-on-exec-flag
(c) add cloexec argument to some functions and a sys.setdefaultcloexec() function to change the default value of cloexec (will be False at startup)
http://www.python.org/dev/peps/pep-0433/#add-a-function-to-set-close-on-exec-flag-by-default
If you care about backward compatibility, (a) is the safest option.
If you care about bugs and security, (b) is the best option. For example, (a) does not fix os.urandom().
(c) tries to be a compromise, but has its own drawbacks.
Victor
- Previous message: [Python-Dev] fork or exec?
- Next message: [Python-Dev] fork or exec?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]