Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!ll-xn!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Endless WaitIO() in VT100 ... sorry, wrong.
Message-ID: <8710220821.AA17309@cory.Berkeley.EDU>
Date: Thu, 22-Oct-87 04:21:53 EDT
Article-I.D.: cory.8710220821.AA17309
Posted: Thu Oct 22 04:21:53 1987
Date-Received: Sat, 24-Oct-87 20:43:40 EDT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 31

>Actually, there is a definite race condition when you use AbortIO to 
>abort a request. Since the request may actually finish just before the
>call to AbortIO, if you then do a WaitIO you will never return because
>the there is no request there! So you probably want to add a call to 
>CheckIO to make sure the request still exists before waiting on it, thus
>the code would look something like ...

	Nope, there isn't.  WaitIO() returns immediately if the request
has already completed.  Therefore, one proper sequence is:

	AbortIO(request)
	WaitIO(request)

	Which (A) asks the device driver to please abort the request and
(B) waits for the request to be returned.  You can then check io_Error to
see if the request completed before it could be Aborted.  (A device which
does not support AbortIO() simply continues processing the request and it
is returned normally).

	As I said before, the only way WaitIO() might freeze up is if
the request was never sent to the device... for example, two WaitIO()'s
in a row without an intervening Do/SendIO.

	As far as the serial device goes, there is another possibility...
If the serial device is XOFF'd WRITE io requests will not be returned until
it is XON'd again, or a FLUSH sent to the serial device.  Any terminal
program which uses XON/XOFF and which doesn't have a timeout limit for 
serial write's (before it tries to AbortIO them) might freeze up on a
spurious XON.

				-Matt