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:

  1. Create multiple threads of control (processes or threads) and have each call block in its own thread.

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

  3. Make these sockets nonblocking using fcntl or ioctl.

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.