This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients Giovanni.Bajo, georg.brandl, gregory.p.smith, jwilk, milko.krachounov, ned.deily, paul.moore, vstinner
Date 2010-12-12.10:11:12
SpamBayes Score 0.0
Marked as misclassified No
Message-id <>

+    _MAXFD = os.sysconf("SC_OPEN_MAX")
+    _MAXFD = 256

It looks like this code (256 constant) comes from Is that a good value? On Linux, SC_OPEN_MAX is usually 1024, and it can be 4096. Should we keep the default value 256, or use 1024 or 4096 instead? I don't know on which OS SC_OPEN_MAX is missing.

-- isopen(fd) uses fcntl.fcntl(fd, fcntl.F_GETFD, 0). Is it always available? If not, we can add fstat() as a fallback. The buildbots will tell us :-)

-- _create_pipe() doesn't use pipe2() because Python doesn't provide pipe2(). We should maybe add it to the posix module (open maybe a new issue for that).

> The CLOEXEC flag needs to be set atomically (or at least in a way
> that another subprocess won't start in the middle of it)

For the Python implementation, the GIL is not enough to ensure the atomicity of a process creation. That's why _posixsubprocess was created. I suppose that other parts of subprocess are not atomic and a lock is required to ensure that the creation of subprocess is atomic.


_posixsubprocess.c: is FD_CLOEXEC flag always available? fcntlmodule.c uses a "#ifdef FD_CLOEXEC".

Can you add a comment to explain why you can release the GIL here? (because the operation is atomic)

+    res = pipe2(fds, O_CLOEXEC);

-- test_pipe_cloexec() and test_pipe_cloexec_real_tools() should maybe be skipped if fcntl has no attribute FD_CLOEXEC.
Date User Action Args
2010-12-12 10:11:14vstinnersetrecipients: + vstinner, georg.brandl, gregory.p.smith, paul.moore, jwilk, ned.deily, milko.krachounov, Giovanni.Bajo
2010-12-12 10:11:14vstinnersetmessageid: <>
2010-12-12 10:11:12vstinnerlinkissue7213 messages
2010-12-12 10:11:12vstinnercreate