[Info-vax] yet another sys$qiow question

[Craig A. Berry]

On 8/21/15 3:57 PM, Stephen Hoffman wrote:
> On 2015-08-21 20:32:00 +0000, Bob Gezelter said:
>
>> I do not recall what the C standard says on the subject offhand, but
>> in general, one must presume when generating code that variables in a
>> global scope are subject to change when invoking an out-of-line
>> subroutine (This was the reasoning behind my previous comments that an
>> out-of-line invocation ends a basic block).
>
> AFAICT, the salient difference here is that the variables involved in
> this case can change after the call has returned; when the variable is
> otherwise apparently and fully back in scope.

Yes, of course the IOSB will change after the return from the SYS$QIO,
but it won't change after you take appropriate steps to make sure the
I/O is complete. As long as those steps include crossing a function
boundary of a function that receives the IOSB as a parameter, no
caching can give you a stale copy.  Specifically:

Returning from SYS$SYNCH is going to force a hard fetch of the IOSB from
its canonical location. It might be cached after that, but that's fine
as the I/O is complete and the IOSB won't change from this point forward.

Entering an AST routine and getting the IOSB by dereferencing the AST
parameter is going to force a hard fetch of the IOSB from its canonical
location. It might be cached after that, but that's fine as the I/O is
complete and the IOSB won't change from this point forward.

Which leaves the event flag case and the polling the IOSB case.

The documentation for using event flags notes that the SYS$WFLxxx
routines do not indicate I/O completion and point to the use of
SYS$SYNCH. So this isn't really a separate case at all.

Which leaves polling the IOSB. All bets are off. Don't do that. The
documentation needs to get some backbone and say it's wrong rather than
gently recommending alternatives.