Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.9 3/12/85; site unisoft.UUCP
Path: utzoo!watmath!clyde!cbosgd!ihnp4!qantel!lll-crg!lll-lcc!unisoft!paul
From: paul@unisoft.UUCP (n)
Newsgroups: net.unix
Subject: Re: Asynchronous I/O on UNIX?
Message-ID: <604@unisoft.UUCP>
Date: Fri, 29-Nov-85 21:14:24 EST
Article-I.D.: unisoft.604
Posted: Fri Nov 29 21:14:24 1985
Date-Received: Sun, 1-Dec-85 03:24:44 EST
References: <248@well.UUCP> <241@ll-xn.ARPA>
Organization: UniSoft Systems, Berkeley
Lines: 28

<oog>

	I too would like to see some form of async I/O under Unix, after
all VMS and even RT11 and the macintosh!! have it.

	The main reason I see against it is that it would massively complicate
unix's very simple user interface (read, when you are done reading do something
else ...). On the other hand you could avoid the problems with some utilities
that have to use more than 1 process to do some very simple things (cu for
example runs 2 processes, one each way, typing a character results in 2
process switches!!!!).

	The major problem in implementation under Unix is the concept of IO
context, with Unix an IO's context (u_base, u_count, u_offset) are in a
processes 'udot' if you are going to be doing multiple IO's you need to be
able to send this information to the device with the queued IO (you also have
to send the process ID, the completion routine's virtual address and the
parameter you are going to give to the completion routine). There is also
and amazing amount of internal synchonisation work needs to be done in the
kernel. And while you are doing that you may as well make it orthoganol
so that all the system calls can have completion routines.

	Rats!! It seemed so easy!! Still it would be nice to see it done ....
sigh ....


		Paul Campbell
		..!ucbvax!unisoft!paul