[Python-Dev] fork or exec?

Antoine Pitrou solipsis at pitrou.net
Thu Jan 10 19:30:13 CET 2013


On Thu, 10 Jan 2013 12:47:23 -0500
Tres Seaver <tseaver at palladion.com> wrote:
> -----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.

Because Python is not POSIX.
(and POSIX did mistakes anyway)

Regards

Antoine.




More information about the Python-Dev mailing list