Path: utzoo!attcan!uunet!husc6!think!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Modem/VT100 problem
Message-ID: <8806182355.AA24196@cory.Berkeley.EDU>
Date: 18 Jun 88 23:55:28 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 48

>	This is exactly right.  However, a program may wish to Wait() if it
>KNOWS it will be signaled, so it can handle other tasks while waiting.
>The best way to KNOW you will be signaled is to CheckIO.  If it hasn't
>completed, you will be signaled when it does.
	
	A very common problem I see in programs is the assumption that
the IO request has completed when a signal is received.  Definately
a bad assumption to make (unless you are *very* careful).  CheckIO()
itself doesn't check to see if the request has already been removed 
from the replyport, only if it has been returned to the reply port.

	So, as you said, the purpose of CheckIO() is to, well, check
if the IO is done yet, independant of any signal that may have occured.

	An io request is:	(1) inactive (not in progress and not
				    returned).  I.e. you haven't 
				    started the IO yet.
				(2) Active but not yet returned
				(3) Active and has been returned, but
				    has not been pulled off the reply 
				    port yet (before you WaitIO()).

				when you pull it off, it is no longer
				Active.

	In most cases, dealing with the Active/InActive state of an io
request (i.e. one that you've SendIO()d vs one that you have pulled 
off the reply port with WaitIO()) is inherent in your software design.
For instance, for serial and console IO I usually always have a request
in progress at all times (for read)... After I process a completed 
request I immediately SendIO() another one.  Thus, there is no question
in any other part of the program that the request is active.

	And since I don't bother to explicitly clear the signal bit
after a WaitIO() (and thus may get false signals), I always call
CheckIO() after receiving a signal to filter out those dirty signals
and call WaitIO() only if CheckIO() returns TRUE.

	However, for WRITEs, my request may be in any of the 3 states
mentioned above, and I need another variable to tell me whether it
is active or not.  I.E. First check the variable, and if it is active
you can then call CheckIO() to determine whether it has been returned
yet, then WaitIO() if it has (or WaitIO() without a CheckIO() if you 
don't mind waiting for it to return).

	I should write a book about it, yah?

					-Matt