[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets (original) (raw)
Cameron Simpson cs at zip.com.au
Sat Jul 6 02:43:52 CEST 2013
- Previous message: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
- Next message: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 05Jul2013 19:03, Victor Stinner <victor.stinner at gmail.com> wrote: | 2013/7/5 Cameron Simpson <cs at zip.com.au>: | > | Both set ONONBLOCK 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 OCLOEXEC on UNIX, and | HANDLEFLAGINHERIT on Windows? (except that HANDLEFLAGINHERIT set | means inheritable, whereas OCLOEXEC 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 passfds | parameter for convinience. It would be surprising to not inherit a | file descriptor passed to Popen in passfds, 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 <cs at zip.com.au>
- Previous message: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
- Next message: [Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]