2013/7/7 Cameron Simpson <c...@zip.com.au>: > On 06Jul2013 14:43, Victor Stinner <victor.stin...@gmail.com> wrote: > | 2013/7/6 Cameron Simpson <c...@zip.com.au>: > | > 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. > | > | Oh... gotcha. I now understood your concern. > | > | There is a little "trick" here: at fork, file descriptors are > | duplicated in the child process and almost all properties (open state, > | flags, offset, etc.) are shared. There is one little exception: file > | attributes are not shared, and there is only one file attribute: > | O_CLOEXEC. Setting O_CLOEXEC in a child process does not affect the > | flag in the parent process ;-) I will add a unit test to check this. > > That's news to me. Interesting. > > I can't find UNIX doco to support this, though I haven't finished > looking. None of the POSIX, Linux or MacOSX fork() manual pages > seem to describe this. > > Can you point me at doco for this? I thought file descriptors were > a direct index into a per-process table of file handle structures, > and did not think the latter got part copies, part shared over a > fork.
Sorry, I found this fact my mistake, not in the doc :-) You can verify this behaviour using the follownig script: hg.python.org/peps/file/tip/pep-0466/test_cloexec.py Output on Linux: initial state: fd=3, cloexec=False child process after fork, set cloexec: cloexec=True child process after exec: fd=3, cloexec=<invalid file descriptor> parent process after fork: cloexec=False parent process after exec: fd=3, cloexec=False "parent process after fork: cloexec=False" means that the flag was not modified in the parent process. > Also, is O_CLOEXEC really the only file attribute? So O_NONBLOCK > is a flag and not an attribute (guessing the terminology distinguishes > these)? Now you mention it, ISTR noticing that there were distinct > ioctls to adjust flags and something else. See the manual page: http://linux.die.net/man/2/fcntl There are "File descriptor flags " and "File status flags", it looks like they are inherited/shared differently between the parent and the child process. > Your change says: > > On Windows, the close-on-exec flag is ``HANDLE_FLAG_INHERIT``. > > I feel it would be clearer to say: > > On Windows, the close-on-exec flag is the inverse of > ``HANDLE_FLAG_INHERIT``. Ok, fixed in the PEP. Victor _______________________________________________ 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
