Path: utzoo!attcan!uunet!husc6!cmcl2!nrl-cmf!ames!oliveb!amdahl!acs
From: acs@amdahl.uts.amdahl.com (Tony Sumrall)
Newsgroups: comp.sys.amiga
Subject: Re: Modem/VT100 problem
Message-ID: <8ccX.e4iTa1010IJOfY@amdahl.uts.amdahl.com>
Date: 18 Jun 88 06:32:44 GMT
References: <8806180105.AA07445@cory.Berkeley.EDU>
Reply-To: acs@amdahl.uts.amdahl.com (Tony Sumrall)
Organization: Amdahl Corporation, Sunnyvale CA
Lines: 80

In article <8806180105.AA07445@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes,
in response to a statement of how VT100 handles the abort of an I/O
operation:
>	The only possible way this could cause a lock up is if the
>signal got cleared AFTER the IO request completed but BEFORE the Wait().
>AbortIO() itself does not munge with the signals.  The only way the
>signal can be cleared is if VT100 clears it somewhere (via Wait(), for
>instance).  Thus, the bug is in *ANOTHER PART* of VT100.
>
>	Besides all that there is absolutely no reason to put a Wait()
>before WaitIO().  WaitIO() works no matter what the state of the signal
>bit is.

Yeah, but there was a *significant* discussion around about 2nd queater
last year on exactly how to successfully abort an I/O.  I remember Leo
being involved and even CATS (Randy Weiner).  In fact, Leo wrote (in
article 3213@well.UUCP:
>	Try this:
>
>	AbortIO (ConsoleRead);
>	WaitIO (ConsoleRead);
>	Wait (1L << ConsoleRead -> io_Message -> mn_ReplyPort -> mp_SigBit);
>
>	When I was writing Robotroff, there were occasions that I would need
>to AbortIO() a timer request so I could reconfigure things.  I AbortIO()ed,
>then WaitIO()ed.  I flushed it, right?
>
>	Apparently not.  I would keep getting this phantom signal that
>Wait() would respond to.  I surmised that the AbortIO() posted a reply to
>your reply port, raising a signal bit.  WaitIO() apparently then checks to
>see if the queue has anything.  If so, it grabs it right away, and doesn't
>bother to clear the signal bit.  So you still have an outstanding signal
>pending to your task... er.. process... er.. whatever.  The above convoluted
>Wait() statement will clear it.
>
>	I suspect that, when you post the new request, then wait for it, the
>old signal somehow gets in and fouls things up.
>
>	If CATS would like the code that created this condition, I'm sure I
>could hack something together.
>
>	Be warned, however, that I have a sneaking suspicion that the above
>hack has a very low probability of working for you....

Is there new information that I somehow missed?  I'm not *that* heavily
into the Amiga (insofar as I've never disassembled any of the code) but
I've followed the discussions here on the net pretty closely and never saw
this particular point brought to light.

Back to Matt:
>	A common problem which you might look for is the programmer
>forgetting set the node type of the IO request to NT_MESSAGE before
>SendIO(), BeginIO(), or DoIO() (not sure about needing it in DoIO()).
>PutMsg() does this for you, but SendIO()/BeginIO()/DoIO() usually don't
>(it depends on the device).
>
>	Just as PutMsg() sticks in NT_MESSAGE automatically, ReplyMsg()
>sticks in NT_REPLYMSG or NT_FREEMSG automatically.  This is how WaitIO()
>figures out whether the request has been returned by the device yet or not.
>(IOF_QUICK is also checked but that's another story).  Since one doesn't
>PutMsg() to the IO device, one must set ln_Type to NT_MESSAGE manually before
>every SendIO()/BeginIO()/DoIO().

Really?  I know that SendIO() and BeginIO() are rather poorly documented
and they even say that their operation varies based on the device (RKM,
old version) but I can't remember *ever* seeing this in any source (other
than Matt's, perhaps).

I'm not disagreeing on either of the above two points, just asking for
confirmation.

>
>				-Matt


-- 
Tony Sumrall acs@amdahl.uts.amdahl.com <=> amdahl!acs

[ Opinions expressed herein are the author's and should not be construed
  to reflect the views of Amdahl Corp. ]