Python 2.0 - win32pipe routines inclusion for Windows

[Niels Diepeveen]

David Bolen schreef:

> 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.

I had a quick look at the source and as far as I can tell you're doing
something like
    _PyPopenProcs[id(files[0])] = hProcess
when opening, and
    if _PyPopenProcs.has_key(id(file)):
        exit_code = GetExitCodeProcess(_PyPopenProcs[id(file)])
        del _PyOpenProcs[id(file)]
when closing.
Maybe you could change this to something that saves all the file objects
with a reference to the process handle and the number of open pipes,
like:
    procdata = [hProcess, len(files)]
    for f in files:
        _PyPopenProcs[id(f)] = procdata
when opening, and
    procdata = _PyOpenProcs[id(file)]
    procdata[1] = procdata[1] - 1
    if procdata[1] == 0:
        exit_code = GetExitCodeProcess(_PyPopenProcs[id(file)])
    del _PyOpenProcs[id(file)]
when closing

> 
> 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.

I thought that it would be easy to return None instead of 0, but looking
at the code I realise that is not an option. Pity. Still, looking on the
bright side, you *can* get the exit code this way, if you're careful,
and with this approach I think nothing will work worse than it already
did.

> 
> 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.
Well, some way to get at the exit code would certainly be useful, even
if it's not the easiest one imaginable.

> 
> 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?

Posix has only popen. The others are Python-specific. The only
"standard" is probably popen2.py. To get an exit code there you have to
instantiate the Popen3 class explicitly, not through the popen2() and
popen3() helper functions. Then you can call its .wait() method.
Unfortunately win32pipe has no such object.

By the way, wouldn't it be easier to implement all this stuff in Python,
except for the basic Win32 functions? That is the way it is done on
Unix. Surely speed is not an issue. CreateProcess is horribly expensive
anyway.

-- 
Niels Diepeveen
Endea automatisering