Path: utzoo!attcan!uunet!cbmvax!jesup
From: jesup@cbmvax.UUCP (Randell Jesup)
Newsgroups: comp.sys.amiga
Subject: Re: Modem/VT100 problem
Keywords: vt100 bugs
Message-ID: <4057@cbmvax.UUCP>
Date: 18 Jun 88 18:13:31 GMT
References: <6512@jhunix.HCF.JHU.EDU> <1108@damask.UUCP> <5205@batcomputer.tn.cornell.edu>
Reply-To: jesup@cbmvax.UUCP (Randell Jesup)
Organization: Commodore Technology, West Chester, PA
Lines: 18

In article <5205@batcomputer.tn.cornell.edu> riley@tcgould.tn.cornell.edu (Daniel S. Riley) writes:
>I know that there are a number of places within vt100 where it will
>AbortIO() a request,
>Wait() for the signal associated with the port for that IO request, then
>WaitIO() on that IO request.
>This sequence can lead to obscure vt100 lock-ups if the IO happens to
>complete and the signal is cleared somewhere else in the program before
>this code gets executed.

	You've got it right.  The sequence would be safe if no other IO
requests used that port (since nothing else would ever clear the signal).
If multiple IO requests use the port, and DoIO/WaitIO on the other requests
may cause you to miss the signal from the AbortIO()ed request.  I find it
easier to assume the signal means something MAY have come back, so I CheckIO
before deciding to WaitIO.  CheckIO is very fast, and also if I know it's
done, WaitIO never actually waits, so I don't go away and ignore the user.

Randell Jesup, Commodore Engineering {uunet|rutgers|ihnp4|allegra}!cbmvax!jesup