The fact that
sysread are blocking calls has more implications for
the server. A single-threaded
process can invoke only one of these calls at a time, which is fine
if there aren’t too many clients clamoring for the
server’s attention and if no client ties
the server up for too long a time. The real world is ugly, and you
have to resolve this issue. There are three ways of doing this:
Create multiple threads of control (processes or threads) and have each call block in its own thread.
Make these calls only when you are absolutely sure they won’t
block. We’ll call this the “select” approach,
because we use the
select call to ensure that a
socket has something to offer.
Make these sockets nonblocking using
As we shall see, option 2 should be used in conjunction with option 3 in production systems. In all cases, the client code remains unaffected while we try out these options.
Incidentally, there is a fourth option. Some systems support an
asynchronous I/O notification: a
signal is sent to the process if any
socket is ready to do I/O. We will not pay attention to this approach
because there is no way for a signal handler to know which
socket is ready for reading or writing.
Perl doesn’t have threads yet (at
least not officially),
but on Unix and similarly empowered systems, it supports
fork, the way to get process-level parallelism. The server process acts as a full-time receptionist: ...