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 SienkiewiczFrom: 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.