6.1 Introduction
In Section 5.12, we
saw our TCP client handling two inputs at the same time: standard
input and a TCP socket. We encountered a problem when the client
was blocked in a call to fgets (on standard input) and the
server process was killed. The server TCP correctly sent a FIN to
the client TCP, but since the client process was blocked reading
from standard input, it never saw the EOF until it read from the
socket (possibly much later). What we need is the capability to
tell the kernel that we want to be notified if one or more I/O
conditions are ready (i.e., input is ready to be read, or the
descriptor is capable of taking more output). This capability is
called I/O multiplexing and is
provided by the select and poll functions. We
will also cover a newer POSIX variation of the former, called
pselect.
Some systems provide more advanced ways for
processes to wait for a list of events. A poll device is one mechanism provided in
different forms by different vendors. This mechanism will be
described in Chapter 14.
I/O multiplexing is typically used in networking
applications in the following scenarios:
-
When a client is handling multiple descriptors
(normally interactive input and a network socket), I/O multiplexing
should be used. This is the scenario we described previously.
-
It is possible, but rare, for a client to handle
multiple sockets at the same time. We will show an example of this
using select in Section 16.5 in the
context of a Web client.
-
If a TCP server handles both a listening socket
and its connected sockets, I/O multiplexing is normally used, as we
will show in Section 6.8.
-
If a server handles both TCP and UDP, I/O
multiplexing is normally used. We will show an example of this in
Section 8.15.
-
If a server handles multiple services and
perhaps multiple protocols (e.g., the inetd daemon that we
will describe in Section 13.5), I/O
multiplexing is normally used.
I/O multiplexing is not limited to network
programming. Many nontrivial applications find a need for these
techniques.
|
