[Info-vax] QIO Writes to a mailbox

[Michael Moroney]

Jan-Erik Soderholm <jan-erik.soderholm at telia.com> writes:

>Johnny Billquist wrote 2011-11-10 00:05:

>>> The same logic applies. Don't wait for the AST right after the QIO call.
>>> Wait for the AST right before the next QIO call. That is, do any other
>>> processing (that is not depending in the IO completion) without waiting.
>>
>> Um? You don't wait for an AST. There is no "wait for AST" system call.

>No, of course not, since it's an (kind of software) interrupt. But
>nevertheless. The AST must have fired before you make the next QIO.
>I'm not sure what you do, HIB maybe ? Let's say you'll HIB.

HIB won't do it.  The AST will fire, then complete, and the process will
go right back into HIB state.

(some programs are written in such a way that *everything* happens in an
AST. The main loop is just a SYS$HIBER call)

>My whole point is that ("HIB" = "wait for the AST") :

>$QIO => prepare next IO => HIB => $QUI => prepare next IO => HIB....

What you need to know is if the previous $QIO completed.  To do this,
issue a $SYNCH on the EF/IOSB combination right before the $QIO.
(the process will go into LEF, if necessary).

Before the first such call, you'll have to manually set the EF and the
IOSB status to nonzero, or code so there is no $SYNCH call the first time.
Else you'll find yourself waiting (forever) for an I/O that hasn't 
happened yet.

And check the IOSB status to see if something went wrong.