Re^3: poe/win32/fork/threads chat-application

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!

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

Replies are listed 'Best First'.
Re^4: poe/win32/fork/threads chat-application by BrowserUk (Patriarch) on May 15, 2007 at 18:16 UTC
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."	[reply]
Re^5: poe/win32/fork/threads chat-application by Moron (Curate) on May 16, 2007 at 12:27 UTC
Thanks for that. I suppose there are workarounds -- Given that the proposed functionality is in control of both processes, your issue about if one end dies is under the control of the programmer. An inelegant way to avoid the blocking problem is to complete an I/O cycle at regular intervals that either sends a message to reflect what happened in the interval or a "nothing happened" message. But of course it would be better to use intrinsically non-blocking communication in the first place but then you need an event-driven process model. __________________________________________________________________________________ ^M Free your mind!	[reply]