Information Technology Reference
In-Depth Information
thread with an identifier for a connection that has data available, and the thread
can then
read()
from that connection, knowing that the read will immediately
return. After processing the data, the thread then calls
select()
again to wait
for the next message.
Process
select()
read()
select()
read()
OS
handler
handler
handler
handler
handler
handler
Network
msg arrives
msg arrives
In servers, asynchronous I/O allows many concurrent tasks to be in progress
at once. This gives rise to an event-driven programming pattern where a thread
Definition: event-driven
programming pattern
spins in a loop, and on each iteration it gets and processes the next I/O event.
In order to be able to process each event, the thread typically maintains for
each task a continuation, a data structure that keeps track of a task's current
Definition: continuation
state and next step.
Example: Web server.
Handling a web server request can involve a se-
ries of I/O steps: making a network connection, reading a request from the
network connection, reading the requested data from disk, and writing the re-
quested data to the network connection. If a single thread is handling requests
from multiple different clients at once, it needs to keep track of the state of its
processing for each request. For example, the network may divide a client's
request into several packets so that the server needs to make several
read()
calls to assemble the full packet. The server may be doing this request assem-
bly for multiple clients at once, so it needs to keep several per-client variables
(e.g., a request buffer, the number of bytes expected, and the number of bytes
received so far). When new data arrives, the thread uses the network con-
nection's port number to identify which client sent the request and retrieves
the appropriate client's variables using this port number/client ID. It can then
process the data.
Event-driven programming v. threads. Although superficially different,
overlapping I/O with computation and other I/O is fundamentally the same
whether you use asynchronous I/O and event-driven programming or use syn-
chronous I/O and threads. In either case, we block until the next I/O can be
done, restore the state of the task that can make progress, execute the next
step of that task, and save the task's state until it can take its next step. The
differences are whether the state is stored in a continuation or thread control
block and whether the state save/restore is done explicitly by the application
or automatically the threads system.
Example: Receiving from multiple connections.
Consider a simple server
that just collects incoming data from several clients. The pseudocode for the
event-driven and thread-per-client cases are similar:
