do anonymous pipes normally work on NT?

[Georg Mischler]

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.