do anonymous pipes normally work on NT?

[Georg Mischler]

Bill Tutt wrote:
>
>
> radbit at my-deja.com wrote:
> >
> > maybe I'm missing something about what you are looking for:
> > here are 2 test scripts that work as anonymous pipes:
> >
>
> That's not the question...
> Anonymous pipes on NT work wonderfully. (just not
> the way we're expecting from this particular Python context)

Well, at least he solved *my* problem! And after fiddling a
little, it even works with my cat.py as well, and should
work with arbitrary child processes. I'll just have to steal
a readline() method somewhere to make it practical...


The Documentaion provided with VC++ about this stuff
it not very helpful, so you have to try and guess.
Here's what I figured by now: The CreateProcess()
function has several ways to pass handles to child
processes. The way I tried it (passing through
StartupInfo.hStdXxx) only seems to work with disk files,
and not with pipes.

The other way is to assign the handles to the stdxxx
of the current process, and inherit them to the
child. This does work with pipes, and is fundamentally
incompatible with the first approach. In fact, as soon
as you just tell it you want to pass any handles in the
StartupInfo, by assigning STARTF_USESTDHANDLES to it's
dwFlags attribute, inheritance is dead. Still, if
you *want* to pass (file) handles through the
StartupInfo object, you nonetheless *need* to set the
bInheritHandles parameter of CreateProcess() to TRUE.
Go figure...

The least obvious thing though, which I only found
by comparing the working code with mine very carefully,
is that for inheritance to work, the dwCreationFlags
must *not* contain win32process.DETACHED_PROCESS.
The VisualStudio docs (and consequently the win32proc
help file) tell us that this would deny acess to the
*console* of the parent process. In fact, it appears
to cut all connections between the two processes.

many thanks for everybody's assistance in figuring
this out!

> Calling SetStdHandle() is particularly silly as well,
> you shouldn't need to overwrite the current stdout just
> to get this to work.

In fact, This is the way I saw it in several C++ examples
by now, and my own observations make me think that it's
just needed if you want to inherit *pipe* handles.


> > win32file.WriteFile(std_out, 'this method works....')
>
> Calling GetStdHandle shouldn't be necessary either. The CRT
> already grabbed that information for us when Python started up.
>
> The question is why does sys.stdout.write() not seem to work
> without -u when

In my latest experiments this *does* work if the parent
process manages to get the handles across. CreateProcess()
has so many mutually exclusive combinations of parameters
that it's just hard to find the right ones for a particular
purpose.

I don't mind setting and resetting the std handles in the
parent, as long as I get the result I want. But then, I'm
also trying to get along with as little knowledge as possible
about Windows programming. I assume you look at it from a
slightly different angle.


Thanks again to everybody!

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