[net.unix-wizards] asynchronous I/O

Mark Sienkiewicz <sienkiew%udel-eecis2.delaware@udel-relay.ARPA> (12/03/84)

One way you can implement an ugly (but usually functional) fake of
asynchronous I/O is to have two processes connected by a pipe.

For each pending I/O, you have a child process doing the read or write.
When the child returns from the sys call, it writes a record about
what is did on the pipe, then signals the parent.

The signal handler in the parent reads a record off the pipe to
determine what happened, and gather up data if it was an asynchronous
read.  It also calls your completion routine.

Now the ugly part:

This is an awful lot of overhead.  I did see an 8 user talk program that
worked like this.  It allowed people to join and leave in the middle by keeping
a central file for communication.  It worked fairly well as long as the system
wasn't too busy.

Another problem is that if the parent is also doing synchronous I/O,
strange things may happen.  The problem I noticed most often was that
if you are blocked for a read, then another process sends you a signal,
your process jumps off to the signal handler, but the read returns -1.

I can throw together some examples if you want.  As far as I've been
able to tell, there is no other way to do asynchronous I/O. :(

				Mark.

William LeFebvre <phil@rice.ARPA> (12/04/84)

Mark Sienkiewicz...

> Another problem is that if the parent is also doing synchronous I/O,
> strange things may happen.  The problem I noticed most often was that
> if you are blocked for a read, then another process sends you a signal,
> your process jumps off to the signal handler, but the read returns -1.

That's supposed to happen.  The global variable errno will also be set
to EINTR, which indicates:

          An asynchronous signal (such as interrupt or quit),
          which the user has elected to catch, occurred during a
          system call.  If execution is resumed after processing
          the signal, it will appear as if the interrupted system
          call returned this error condition.

(This is under BSD, but I'm pretty sure that things are very similar
under Bell Unix).

If you expect your reads to be interrupted by signals, you should be
prepared to handle the condition and take appropriate action (such as
calling read again).

                                William LeFebvre
				Department of Computer Science
				Rice University
                                <phil@Rice.arpa>