RetroSearch Browse

Wed Jul 17 13:31:14 CEST 2013 · https://mail.python.org/pipermail/python-dev/2013-July/127408.html

2013/7/7 Cameron Simpson <cs at zip.com.au>:
> On 06Jul2013 14:43, Victor Stinner <victor.stinner at gmail.com> wrote:
> | 2013/7/6 Cameron Simpson <cs at 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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2013-July/127408.html below:

[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking sockets