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: <8806182050.AA22868@cory.Berkeley.EDU>
Date: 18 Jun 88 20:50:32 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 56

>>	Try this:
>>
>>	AbortIO (ConsoleRead);
>>	WaitIO (ConsoleRead);
>>	Wait (1L << ConsoleRead -> io_Message -> mn_ReplyPort -> mp_SigBit);
>>

	WRONG!

	WaitIO() may OR MAY NOT clear the signal bit, it depends whether
or not the request has already been returned.  In anycase, if WaitIO()
DOES clear the signal bit, a further Wait() statement will FREEZE the
program.

	This is what WaitIO does (not exactly, but close enough):

	If QUICKIO, return immediately
	If the request is already returned, remove and return immediately
	else Wait() on the signal bit until the request is returned,
	     then remove and return.

WaitIO(ior)
{
    if (ior->io_Flags & IOF_QUICK)
	return(ior);
    while (ior->io_Message.mn_Node.ln_Type == NT_MESSAGE)
	Wait(1 << ior->io_Message.mn_ReplyPort->mp_SigBit);
    Disable();
    Remove(ior);
    Enable();
    return(ior);
}

	NOTE that WaitIO() ONLY calls Wait() if the request has NOT been
returned yet.

	Therefore, after a call to WaitIO(), the state of the signal bit
is COMPLETELY UNKNOWN.  If you really want to get rid of phantom signals,
the proper sequence is: (if you want to abort the request, stick in an
AbortIO() before the WaitIO()).

	long mask = 1 << ior->io_Message.mn_ReplyPort->mp_SigBit;

	WaitIO(ior);
	SetSignal(0, mask);

	In the case where you are using the IO port as a multi-drop
response path, it would probably be better to SET the signal after a
WaitIO() instead of clearing it, so you main-loop Wait() doesn't freeze
up when other requests are present on the replyport:

	WaitIO(ior);
	SetSignal(mask, mask);


					-Matt