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
Message-ID: <8710202353.AA25899@cory.Berkeley.EDU>
Date: Tue, 20-Oct-87 19:53:29 EDT
Article-I.D.: cory.8710202353.AA25899
Posted: Tue Oct 20 19:53:29 1987
Date-Received: Thu, 22-Oct-87 04:01:47 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 22

>Katin of Commodore said that the AbortIO() should be followed by a
>Wait()/GetMsg() pair or, alternatively, a WaitIO() since the abort doesn't
>remove the reply.  Ed changed the WaitIO() with a GetMsg() call with no
>intervening Wait() and, he reports, the problem disappears!
>
>Anyone got the straight scoop?  Doesn't seem that, in a message passing
>system, one should simply do a GetMsg() without a preceeding Wait().

	That's a big negatory... certainly if you remove the Wait() or
WaitIO() it will not endlessly wait, but the only way it could possibly have
screwed up is if the aborted request was never sent in the first place. 
Alternately, the aborted request might have already been processed by a 
Wait()/GetMsg() or WaitIO() and is not pending in the IO device.  Therefore,
you are simply replacing the problem with a possibly more dangerous one.... 
since with your modification it is now possible for the request to get reused
before the IO device is finished with it.

	Can you say CRASH?  I suggest that the original WaitIO() be put back
until the *real* problem is found.


					-Matt