Python 2.0 - win32pipe routines inclusion for Windows

[David Bolen]

Niels Diepeveen <niels at endea.demon.nl> writes:

> I would propose waiting for the child to terminate and returning the
> exit code only when closing the last remaining pipe, and returning None
> on all the earlier closes. Is there any problem with that?

Just a far harder implementation in terms of maintaining state -
internally, the close() function has no automatic access to anything
outside of the file handle - the patch I proposed linked the selected
(stdin) handle to the original process handle, so a wait and retrieve
result could be done, but cross-linking all of the files that relate
to the same process handle, although not impossible, is much more
effort to ensure correctness.

It would also mean subtlety in terms of knowing for sure if you are
getting the exit code or not.  If somehow you didn't actually close
all the file handles you thought you did, you might mistake the
close() return of 0 on what you thought was the final handle for a
successful child process exit when you just hadn't happened to close
all handles yet.

Hmm - maybe implementing pclose() semantics in a popen#() environment
(e.g., not the normal plain popen()) isn't practical - I agree that we
don't want to leave the potential for a deadlocked wait for a child
process that an application can't protect against.

Does anyone know if the higher order popen# calls part of Posix?  Does
it have defined behavior for retrieving exit codes in such a case?

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/