On 05Jul2013 10:41, I wrote:
| On 04Jul2013 13:03, Victor Stinner <victor.stin...@gmail.com> wrote:
| | Other Changes
| | -------------
| | The ``subprocess.Popen`` class must clear the close-on-exec flag of file
| | descriptors of the ``pass_fds`` parameter.
|
| I would expect Popen and friends to need to both clear the flag to
| get the descriptors across the fork() call, and _possibly_ to set
| the flag again after the fork. Naively, I would expect the the flag
| to be as it was before the Popen call, after the call.
This is harder than I'd thought through.
Descriptors go across a fork() anyway, and after an exec() there is nobody to
change their state.
In order for the parent to restore the prior close-on-exec state
(if deemed the right thing to do) it would need to know when the
exec was done in the child.
You'd need something like an extra descriptor attached to a pipe
marked close-on-exec so that the parent could see EOF on the read
end after the exec, since the exec would close the write end.
tractable, but baroque.
So I'd have the PEP take a position on the post-exec() state of the
passed file descriptors, and if state is not going to be restored
it should outright say that passing an fd clears the close-on-exec
flag. Which is it does, but I think the doco should be pretty overt
about:
- this side effect of clearing close-on-exec on these fds
- that the file descriptor and its close-on-exec state is common
between the parent and the child
- that setting of close-on-exec on the fds in the parent could
in principle comprimise the exec in the child if done too soon
If you decide state should get restored, the implementation gets a
bit fiddlier to detect the exec() in the child. I can't speak for
what might be required on non-UNIX.
Cheers,
--
Cameron Simpson <c...@zip.com.au>
Agree, for Law is costly. -- Very good advice to litigious Persons, founded
upon Reason and Experience; for many Times the Charges of a Suit exceed the
Value of the Thing in Dispute. - Bailey's dictionary, 1736
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
