[Python-Dev] fork or exec? (original) (raw)

Tres Seaver tseaver at palladion.com
Thu Jan 10 18:47:23 CET 2013

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 01/10/2013 07:52 AM, Antoine Pitrou wrote:

Le Thu, 10 Jan 2013 12:59:02 +0100, Victor Stinner <victor.stinner at gmail.com> a écrit :

2013/1/10 Charles-François Natali <neologix at free.fr>: Disclaimer: I'm not saying we should be changing all FDs to close-on-exec by default like Ruby did, I'm just saying that there's a real problem.

I changed my mind, the PEP does not propose to change the default behaviour (don't set close-on-exec by default). But the PEP proposes to add a function to change the default behaviour. Application developers taking care of security can set close-on-exec by default, but they will have maybe to fix bugs (add cloexec=False argument, call os.setcloexec(fd, True)) because something may expect an inheried file descriptor. Do you have an example of what that "something" may be? Apart from standard streams, I can't think of any inherited file descriptor an external program would want to rely on. In other words, I think close-on-exec by default is probably a reasonable decision.

Why would we wander away from POSIX semantics here? There are good reasons not to close open descriptors (the 'pipe()' syscall, for instance), and there is no POSIXy way to ask for them not to be closed.

Tres. - --

Tres Seaver +1 540-429-0999 tseaver at palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlDu/qsACgkQ+gerLs4ltQ5zxACgu9+OcQx9iMgm9YosUhausoIo orwAoK5NNzGDkC0MKwR8oRDCYTz3zNl4 =TPKH -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list