Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!watmath!clyde!cbosgd!ihnp4!zehntel!hplabs!hao!seismo!brl-tgr!tgr!Mark Sienkiewicz 
From: Mark Sienkiewicz 
Newsgroups: net.unix-wizards
Subject: asynchronous I/O
Message-ID: <6302@brl-tgr.ARPA>
Date: Mon, 3-Dec-84 13:03:54 EST
Article-I.D.: brl-tgr.6302
Posted: Mon Dec  3 13:03:54 1984
Date-Received: Thu, 6-Dec-84 06:33:12 EST
Sender: news@brl-tgr.ARPA
Organization: Ballistic Research Lab
Lines: 29



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.