n the documentation mentally translate "server" into "parent" and "client" into "child" for your case.

... and it won't work. To understand why it won't work you'll have to try it. Oh, but your " not a Windows person". That explains a lot.

I am sure the community would benefit from your explanation rather than just your conclusion (if you should have time?) - I got the idea of using Win32::Pipe from the big camel book chapter 16 - and I can't try it out at work because I am hired as a unix programmer and have a paranoically restrictive PC environment to contend with.
__________________________________________________________________________________

^M Free your mind!

From the POD for Win32::Pipe:

If someone is waiting on a Read and the other end terminates then you will wait for one REALLY long time! (If anyone has an idea on how I can detect the termination of the other end let me know!)

All pipes are blocking. I am considering using threads and callbacks into Perl to perform async IO but this may be too much for my time stress. ;)

By splitting the problem into two processes that communicate via a blocking pipe, you've just recreated the original problem. Twice.

Instead of a single process that has the problem of servicing a (non-blocking) keyboard and a blocking socket, you now have two processes.

• One has to try and concurrently service a (non-blocking) keyboard and a blocking pipe.
• The other has to try and service a blocking socket and a blocking pipe.

Sockets can be set non-blocking, pipes (via Win32::Pipe) cannot.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."