Handling Multiple Clients
The fact that
accept
, read
, and
sysread
are blocking calls has more implications for
the server.[48] 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
fcntl
orioctl
.
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 SIGIO
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.
Multiple Threads of Execution
Perl doesn’t have threads yet (at
least not officially[49]),
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: ...
Get Advanced Perl Programming now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.