[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