Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!ptsfa!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: a very simple question on DoIO/GetMsg/device drivers
Message-ID: <4815@well.UUCP>
Date: 22 Dec 87 22:55:59 GMT
References: <890@louie.udel.EDU>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Distribution: na
Organization: Bleep Gzorp!
Lines: 54

In article <890@louie.udel.EDU> rminnich@udel.EDU (Ron Minnich) writes:
>   Telnet gets the news. It does a CheckIO(Request), which returns
>non-zero value. It also does a WaitIO for grins, and gets a zero
>				^^^^^^  <-- Significant
>back. Then the fun begins. The port in this case is called tcpinp.
>If i look at tcpinp->MsgList (not the exact name), the lh_Head
>points to Request, and lh_TailPred points to Request. But a 
>GetMsg(tcpinp) returns a 0! How can this happen?

	It pays to keep the OLD manuals around:

Rom Kernel Manual >> V1.0 <<, p. 6-6:
	"DoIO will internally use the ReplyPort; when the IO is completed,
you "know" that your IORequest block is again free for re-use.  DoIO puts
your task to sleep waiting for the return of the IORequest block at the
ReplyPort, then wakes up your task automatically removing the message from
the port for you.

	"...WaitIO, as with DoIO, also internally uses the ReplyPort.  If
you use WaitIO, it will not be neccesary to use GetMsg after your task
awakens."

	Personally, I too find it curious that your MsgPort's MsgList still
still points at IORequest.  However, have you checked the entries in your
IORequest's io_Message.mn_Node structure to see if they're still pointing to
the list header?

>  Then, to top it off, if i do a SendIO(Request), the whole machine
>locks up tight as a drum. 

	Now that *is* weird.  I strongly suggest inspecting the
io_Message.mn_Node structure to see what it says.  It could be that the
call to GetMsg() is messing things up.

	Wild Guess:  GetMsg() looks at the header and finds the IORequest.
GetMsg() then moves to the IORequest to dequeue it, and finds that the node
structure is not linked to the header.  GetMsg() gets hopelessly confused,
screws something up, and returns a NULL.  The next call to SendIO() causes
the system to discover GetMsg()'s screw-up, and gets really lost.

	One thing seems certain, however:  If you're using WaitIO() for I/O
completion, you shouldn't use GetMsg(), too.  And if you're using GetMsg()
or WaitPort(), you shouldn't be using WaitIO().

	Dale?  Jimm?  Bart?  Could one of you dig up Carl Sassenrath and ask
him to comment on this?  The operation of the I/O system has never been
totally clear.  It'd be nice to get Carl's gospel on all aspects of I/O and
its relation to the message system.  Maybe we should invite him to speak at
a BADGE meeting.....

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_		Recumbent Bikes:	      dual ---> !{well,unicom}!ewhac
O----^o	      The Only Way To Fly.	      hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor