[Scons-dev] subprocess

[Gary Oberbrunner]

On Mon, Jun 25, 2012 at 7:54 AM, TOM TANNER (BLOOMBERG/ LONDON)
<ttanner2 at bloomberg.net> wrote:

> I see that the subprocess.Popen call passes all open file descriptors to the child process.

>

> Silly question I suppose - but, is that safe? Should it use close_fds=True. normal make presumably wouldn't have that issue, but do people use this facility in scons?


Stdout and stderr need to be passed of course, whether or not they're
being redirected.  Others I don't think matter.  Here's a related
changelog entry (very old) from 1.3.x, before there was such a thing
as subprocess (or before we could use it anyway):

==============================

-- SCons REDEFINES PYTHON open() AND file() ON Windows TO NOT PASS
ON OPEN FILE HANDLES TO CREATED PROCESSES

On Windows systems, SCons now redefines the Python open()
and file() functions so that, if the Python Win32 extensions
are available, the file handles for any opened files will *not*
be inherited by subprocesses, such as the spawned compilers and
other tools invoked to build the software.

This prevents certain race conditions where a file handle for
a file opened by Python (either in a Python function action,
or directly in a SConscript file) could be inherited and help
open by a subprocess, interfering with the ability of other
processes to create or modify the file.

In general, this should not cause problems for the vast majority
of configurations. The only time this would be a problem would be
in the unlikely event that a process spawned by SCons specifically
*expected* to use an inherited file handle opened by SCons.

If the Python Win32 extensions are not installed or are an
earlier version that does not have the ability to disable file
handle inheritance, SCons will print a warning message when the
-j option is used. The warning message may be suppressed by
specifying --warn=no-parallel-support.


-- 
Gary