Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!mit-eddie!genrad!decvax!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Transparent Asynchronous I/O.
Message-ID: <8709061954.AA00920@cory.Berkeley.EDU>
Date: Sun, 6-Sep-87 15:54:17 EDT
Article-I.D.: cory.8709061954.AA00920
Posted: Sun Sep  6 15:54:17 1987
Date-Received: Sun, 6-Sep-87 22:36:59 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 29


>If the program doesn't wait for the I/O to finish
>
>1.  Don't you loose one good place for a context swithc, and therefore have
>    a weaker multitasking?
>
>2.  How do you know an I/O operation has failed?  You don't get a return
>    code since you didn't wait for the I/O to finish.  You would get some
>    asynchronous interrupt saying "I/O operation failed on some port some
>    time in the past."  Diagnosis will be a major pain.

(1)	No.  The only difference between asyncronous and syncronous IO is
	that we do not wait for the message to come back before allowing
	the caller to resume.  Since the caller explicitly wants asyncronous
	IO, one can assume the request will take a while and that the caller
	wants to do other things in the mean time.
	
(2)	Obviously, you can't know immediately whether the operation failed.
	The returned error code would be for the previous operation, with
	the XFCLOSE() call returning the error code for the final operation.

	BTW: We can only have one pending IO request per file handle anyway
	or AmigaDOS blows up.


	I don't understand what people are arguing about.  I use asyncronous
IO in both DTERM and DME and it works great!

					-Matt