[Python-Dev] fork or exec?
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.set_cloexec(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