On Dec 18, 7:21 pm, "Gabriel Genellina" <gagsl-...@yahoo.com.ar> wrote: > En Thu, 18 Dec 2008 19:46:45 -0200, Aaron Brady <castiro...@gmail.com> > escribió: snip > On Windows, file handles are the real OS stuff, the "true" reference to an > open file. File descriptors are not, they exist only to please the C > runtime library. Programs not written in C (directly, or indirectly like > Python) don't care at all about file descriptors. And in case one actually > cares, there is _open_osfhandle in the C RTL (available as > msvcrt.open_osfhandle from Python). > A subprocess may inherit handles from its parent [there are two filters: > the parameter "bInheritHandles" in the CreateProcess call provides global > control, and individual handles can be made inheritable or not, before > creating the new subprocess]. > "Anonymous" pipes are good to replace stdin/stdout/stderr, because there > is no need to explicitely communicate the handle value to the subprocess: > one just replaces the corresponding handle with the desired pipe, and the > subprocess might not even notice it. > In case this is not enough, one might pass the handle (as a number) in the > command line, but probably a "named pipe" would be better. As this is not > transparent for the child process, one must explicitely code such things. > > > Will it take calling > > 'CreatePipe' from ctypes directly if on Windows? Or can 'os.pipe' be > > made to abstract that? If Windows can't inherit descriptors, > > 'os.pipe' should return handles, and 'os.read' &co. should accept > > them. > > I think the best way would be to modify os.pipe so it returns inheritable > pipes, as it should have been from the beginning. > > > It is a fairly large patch. > > Not at all, you have already posted most of it.
I have marginally tested the patch on a custom build. It works, but there is a catch. The descriptor can't be passed directly to the child on the command line. You need to call 'msvcrt.get_osfhandle' on the descriptor, pass the result, then call 'msvcrt.open_osfhandle' in the child. -- http://mail.python.org/mailman/listinfo/python-list
