🚀 go-pugleaf

In article <1498.AA1498@julie> mcr@julie.UUCP (Michael Richardson) writes:
>  Hmm. I believe that WaitIO() doesn't call Wait() if the request has
>already arrived. I would expect that it checks the ln_Node member for
>NT_REPLY, and if found Remove()s the entry from whatever message queue
>it is on. If not it Wait()s for the signal, and does the check again.

That is basically correct, WaitIO() doesn't call Wait() unless the
IOF_QUICK bit is clear *and* the node type is *other than* NT_REPLY.

The IOF_QUICK bit indicates that the request was completed quickly,
and thus the device did not do a ReplyMsg().  The node type NT_REPLY
indicates that the request was *not* completed quickly, but the device
has completed it, and used ReplyMsg() to send it back to you.  Either
way, the request is complete and there is no need for WaitIO() to
Wait().

>Why a Wait() _after_ the WaitIO() request doesn't block, I'm not sure...

The signal bit was probably left on because the device did a
ReplyMsg(), but WaitIO() never called Wait(), so the mn_ReplyPorts's
signal bit was never cleared, but you can't rely on this!  Your
program will probably hang under certain (hard to reproduce)
conditions.  The moral is: Don't call Wait() to wait for the
mn_ReplyPort's signal because it might or might not have been cleared
(or even set if the request was completed quick).

In summary, WaitIO() knows how IO works so you don't need to.  You can
ignore all these details about IO handling if you remember what Bob
Burns pointed out in an earlier followup.  To abort IO requests (yes,
even timer.device requests):

	AbortIO(Req);
	(void)WaitIO(Req);

The (void) above indicates that we don't care what the result
(io_Error) of the request was.

-hans