On Mon, Jun 25, 2012 at 7:54 AM, TOM TANNER (BLOOMBERG/ LONDON) <[email protected]> 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 _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
