Path: utzoo!utgpu!watmath!clyde!att!rutgers!mailrus!ames!pasteur!ucbvax!POSTGRES.BERKELEY.EDU!dillon
From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga.tech
Subject: Re: IOQuestion
Message-ID: <8901090823.AA21901@postgres.Berkeley.EDU>
Date: 9 Jan 89 08:23:01 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 32

: I write:
:>    Also, many people forget to set the ln_Type field of *any* IO
:>request to NT_MESSAGE before calling DoIO()/SendIO()/BeginIO().  In the
:>case of the audio.device it doesn't matter anyway since the audio.device's
:>returning of requests is broken.
gay@elde.epfl.ch (David Gay) Writes:
:Does this mean that there are devices which pass the IORequest to the task
:(or whatever) that actually does the work w/o using PutMsg (which will set
:the ln_Type field to NT_MESSAGE) ? (or w/o setting ln_Type to NT_MESSAGE in
:the BeginIO call)

	I was saying two things in that message:

	(1) I seem to remember that some IO devices did not set the ln_Type
	    field to NT_MESSAGE when you did a BeginIO() (i.e. DoIO(),
	    SendIO(), or BeginIO()).  In order for WaitIO() to work, the 
	    request's ln_Type field MUST be NT_MESSAGE until it gets
	    returned.  This does not effect requests that can be done with
	    QUICKIO because WaitIO() checks the IOF_QUICK flag.  Thus, I
	    always set the ln_Type field to NT_MESSAGE *before* doing the
	    DoIO()/SendIO()/BeginIO().

	    (anybody know if this was fixed?)

	(2) IO devices always set the ln_Type field to NT_REPLYMSG when they
	    return a request... well, actually, ReplyMsg() is what does this.
	    This is how WaitIO() knows when a request has been returned.

	    Except the audio.device has a bug and doesn't do this.

					-Matt