Non-blocking i/o is totally cool for those situations when it really matters, like "I don't know when that %^&#!! user is gonna hit a key, but as soon as he does, BOY am I gonna whack him!"... Event-driven I/O works best for filehandles that have been placed into nonblocking mode. In blocking mode, a "print" command may block if you give it more data than the under lying file or device can accept, and a "<>", "sysread" or "read" command will block if you attempt to read more data than is ready; no events will be processed while the com mands block. In nonblocking mode "print", "<>", "sysread" and "read" never block. See the documentation for the individual commands for information on how they handle blocking and nonblocking filehandles.
update: (A less vindictive application would be a case like a server that may be accepting connections and input data from any number of clients. Once it has one or more clients connected, it merely wants to try to read from each one, and if there's something to read, handle that; otherwise, don't just hang, waiting on a lagging client -- move on! See if there's another connection request, look for input from other clients, keep busy!)
In reply to Re: IO::File->blocking
by graff
in thread IO::File->blocking
by Flame
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |