in reply to poe/win32/fork/threads chat-application

I'm not a Windows person, but I've noticed that there's a start command available in Windows for spawning a process - by default without wait. The two processes can communicate using Win32::Pipe - in the documentation mentally translate "server" into "parent" and "client" into "child" for your case.
__________________________________________________________________________________

^M Free your mind!

  • Comment on Re: poe/win32/fork/threads chat-application

Replies are listed 'Best First'.
Re^2: poe/win32/fork/threads chat-application
by BrowserUk (Patriarch) on May 15, 2007 at 13:12 UTC
    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.


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