On 05Jul2013 19:03, Victor Stinner <victor.stin...@gmail.com> wrote:
| 2013/7/5 Cameron Simpson <c...@zip.com.au>:
| > | Both set O_NONBLOCK flag (UNIX)
| >
| > Oh, how embarassing.
|
| You said that the PEP is not cristal clear. Do you have a suggestion
| to make it more clear?
|
| Should I mention that the close-on-exec flag is O_CLOEXEC on UNIX, and
| HANDLE_FLAG_INHERIT on Windows? (except that HANDLE_FLAG_INHERIT set
| means inheritable, whereas O_CLOEXEC set means *not* inheritable)
It wouldn't hurt.
Otherwise, colour me mostly convinced.
I've read your "Rejected Alternatives" more closely and Ulrich
Drepper's article, though I think the article also supports adding
a blocking (default True) parameter to open() and os.open(). If you
try to change that default on a platform where it doesn't work, an
exception should be raised.
| The close-on-exec flag only affects inheritance of file descriptors at
| the execv() syscall, not at fork(). And execv() can be called without
| fork().
Yes. Please forget I mentioned fork(); it is only relevant if you
were offering some facility to undo the addition of cloexec to a
Popen passed file descriptor. Which you are not.
| Popen must clear close-on-exec flag on files from its pass_fds
| parameter for convinience. It would be surprising to not inherit a
| file descriptor passed to Popen in pass_fds, don't you think so?
Yes yes yes.
| I don't understand. I already wrote "The flag has no effect on fork(),
| all file descriptors are inherited by the child process" in the PEP.
| It is not enough? Do you have a suggestion to explain it better?
My concerns are probably as well bundled with concerns about users
not realising the a file descriptor state after a fork is shared,
and then being confused if the other process did a seek() etc.
I think I'm just concerned about a naive caller using this scenario:
# gather up some already open fds to pass
fds = (5,6,7)
P = Popen(...., pass_fds=fds)
# now restore the cloexec state from before
for fd in fds:
os.set_cloexec(fd)
where the cleanup loop in the parent gets to run before the exec()
in the child.
We could just consider it one of the pitfalls of fork/exec situations
in general an expect people being this fiddly to need to add some
synchornisation.
Please consider your argument won.
Cheers,
--
Cameron Simpson <c...@zip.com.au>
_______________________________________________
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
