A RetroSearch Logo

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

Search Query:

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

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

[Python-Dev] PEP 446: Add new parameters to configure the inherance of files and for non-blocking socketsCameron Simpson cs at zip.com.au
Sun Jul 7 02:29:12 CEST 2013
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.

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.

| I modified the PEP to explain that, and I also mentioned the name of
| the close-on-exec and blocking flags:
| http://hg.python.org/peps/rev/425f831fddf7

Thanks.

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``.

or

  On Windows, the close-on-exec flag implemented using ``HANDLE_FLAG_INHERIT``.

(This latter is fine because the rest of the paragraph explains the
meaning of HANDLE_FLAG_INHERIT.)

The bare "is" in your current wording suggests to me that the
truthiness (ick!) of close-on-exec is the same as for HANDLE_FLAG_INHERIT,
which it isn't.
-- 
Cameron Simpson <cs at zip.com.au>

I've always been a big Greenaway fan - I've seen and enjoyed "The Falls" for
crying out loud.        - Peter Alexander Merel <pete at extro.ucc.su.OZ.AU>
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4