do anonymous pipes normally work on NT?
Georg Mischler
schorsch at schorsch.com
Sun Jun 13 08:24:33 EDT 1999
Mark Hammond wrote:
> Nothing is particularly obvious, although the code is too large
> to really be sure.
Thanks for looking into it.
> * Have you seen win32pipe.popen*?
Yes I did. The trouble is that I need to store the pid
(and tid on NT), since the started process can live
longer than the parent. If I want to regain control
over the child again later (for stopping it etc.) then
I can't use any of the popen*s. Also, in some cases
I need to redirect stdout to a file (which works fine).
> * I can't see where you keep references to the handles
> for the sub-process.
> Is it possible that the handles are being closed by the
> parent process, thereby closing the child process handles?
I was afraid of that too. I save all necessary handles as
self.hStd{Input|Output|Error}, self.hProcess and self.hThread
(assuming that I actually save the right ones...). Those
handles are only closed in self.__del__() long after my
problem arises.
> * Personally I would use win32file.CreateFile instead of
> os.open/msvcrt.get_osfhandle. One advantage is that a
> layer of indirection you are now using is removed.
This has a technical point. Otoh, it's one of the things
that *do* work right now. I'll check seperately, if your
suggestion changes anything.
> Second advantage is that you deal with > "PyHANDLE" objects,
> and explicit closing is not necessary (a-la files)
I seem to remember a post by someone (you?) who stated
that *not* closing Windows handles on could lead to serious
resource leaks. Am I confusing something here or are
not all handles created equal?
> * You may have more luck spotting the problem (or getting
> someone else to) if you provide all this in a single,
> general purpose function.
>
> def CoProc( command_line, infile, outfile ):
> ...
>
> with all command-line parsing and other app specific stuff
> that doesnt relate to the problem removed.
Yes, I guess I'll have to do this. I stripped it down
allready to a certain degree, but there's still some
unrelated stuff in there (In my application context it's
a tiny piece of code the way it is, but that obviuosly
doesn't help an external observer to understand it...)
I'll be back after some more fiddling.
Thanks a lot
-schorsch
--
Georg Mischler -- simulation developper -- schorsch at schorsch.com
+schorsch.com+ -- lighting design tools -- http://www.schorsch.com/
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
More information about the Python-list
mailing list