[Info-vax] yet another sys$qiow question

[VAXman- at SendSpamHere.ORG]

In article <55d73789$0$19629$c3e8da3$b1356c67 at news.astraweb.com>, JF Mezei <jfmezei.spamnot at vaxination.ca> writes:
>On 15-08-21 09:41, Johnny Billquist wrote:
>
>> Uh? It's a completely valid and not poor practice to check the iosb 
>> before the operation completes. And the IOSB is defined as being set to 
>> zero by the initiation of the I/O.
>
>
>Pardon my ignorance here, but what purpose is served by checking the
>IOSB before the IO completes ?

It would serve no purpose.  There are *proper* ways to handle the IOSB!
$SYNCH, which would wait the thread of execution until the I/O has been
completed and then, and only then, would one want to check the IOSB for
completion status.  Another alternative would be to queue the I/O with
a completion AST and then, when the AST is delievered, check the IOSB.
Polling the IOSB would be a stupid waste of CPU time.  


  
>Is this some performance thing to check IOSB for non-zero value instead
>of checking if event-flag has been set ?

What if you had no event flag?  VMS now has EFN$C_ENF (a does not exist
event flag) for use in multi-threaded code.  I've taken to specifying it
in most system services which maintain an event flag parameter.  The IOSB
should still only be checked for status (and its other fields should only
be used) after completion of the service.  See above: $SYNCH or AST.


>I've always done either QIOW, or QIO with AST or QIO with event flag. I
>personally really like the AST model.

Then, you've answered your own question.  $QIOW is just a $QIO/$SYNCH.
You should ALWAYS specify the IOSB.  Event flags can be problematic if
using multiple threads but one is always specified in some form (ie. a
value EFN or EFN$C_ENF).  Using the mechanisms you described, the IOSB
is valid when you look at it.

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.