[Info-vax] yet another sys$qiow question

[David Froble]

Bob Gezelter wrote:
> On Saturday, August 22, 2015 at 3:32:49 PM UTC-4, David Froble wrote:
>> Bob Gezelter wrote:
>>> On Saturday, August 22, 2015 at 12:29:06 AM UTC-4, JF Mezei wrote:
>>>> I think I understand the volatile issue.
>>>>
>>>> However, since the IOSB is a structure, pedandically speaking, wouldn't
>>>> the compiler treat each member of the structure independantly ?
>>>>
>>>> aka: reading the first member repeatedly might cause it to be optimized
>>>> to register (or optimized away), but even if it has happened, reading
>>>> the second member of structure would cause a memory fetch of the second
>>>> value.   Right ?
>>>>
>>>>
>>>> What about character buffers ?
>>>>
>>>> Say I put 0x00 as first byte of a 250 byte char buffer. Call QIO to read
>>>> data into buffer, and then loop until the first byte of buffer is no
>>>> longer 0 (I know, even worse practice than looing to check IOSB :-)
>>>>
>>>>
>>>> Would the compiler also optimize this loop away, even if it is character
>>>> data ?
>>>>
>>>> From a programmer's point of view, if I were to test for
>>>> strlen(buffer) != 0
>>>>
>>>> How do I know as a programmer whether "strlen" will be considered an
>>>> external routine (which will impart "volatile" on buffer), or  a known
>>>> routine which the compiler will inline code, and then optimize because
>>>> it knows that strlen won't modify buffer so the whole thing can be
>>>> optimized away ?
>>>>
>>>> If I declare buffr as "volatile", it is correct to state that I no
>>>> longer have to worry about whether a routine is external or inline code
>>>> since buffer will always be assumed it could change ?
>>> JF,
>>>
>>> Looking at the contents of a buffer BEFORE completion is not simply "a worse"
>>> practice. It is out-and-out wrong.
>> Ayep ...
>>
>>> From the time that an IO operation is initiated (e.g., QIO call), till the
>>> time of IO Post processing, which updates the IOSB, sets the event flag, and
>>> queues (not invokes) the AST (ASTs are queued FIFO by access mode within a
>>> process), the contents of a buffer are UNDEFINED.
>>>
>>> UNDEFINED means UNDEFINED. There are (literally) NO LIMITS on what a driver
>>> may do with a buffer. There are no requirements of consistency between
>>> related devices (e.g., TTDRV, LATDRIVER, TNADRIVER). The contents of the
>>> buffer may be zeroed, may contain junk, may be filled in any order convenient
>>> to the driver (e.g. consider the cases of magtape Read Reverse).
>>>
>>> A more dangerous problem is an IOSB or buffer going out of scope. If a buffer
>>> or IOSB is allocated on the stack, and the routine returns before the
>>> operation completes, the stack can get arbitrarily corrupted, with the
>>> unpredictable results.
>>>
>>> - Bob Gezelter, http://www.rlgsc.com
>> If you're going to exit a routine that queued up a QIO, or other async service, 
>> before the operation is complete, then don't cha think that cancelling the thing 
>> might be the thing to do?  If I remember correctly, and no, I haven't done much 
>> of this, the AST would then never be queued.  Nor should it.
>>
>> If I remember correctly,
> 
> David,
> 
> Au contraire. $CANCEL indeed cancels IO. However, as documented in the IDSM (The hardcover 5.2 version, Section 21.9, pp 624, et seq.), the canceled IRP is queued for normal POST PROCESSING with an IOSB status of SS$_CANCEL.
> 
> Thus, completion processing is assured (if the process does not exit first). However, some drivers may not cancel already active IO operations (e.g., disk reads/writes). 
> 
> Thus, SS$_CANCEL is only assured for IOs that have been queued, but not actually initiated by the driver. Cancellations of active IOs may yield SS$_CANCEL or might succeed, at the driver's option.
> 
> - Bob Gezelter, http://www.rlgsc.com

Ok, then let me ask.  If you cancel the operation, would that not then cause the 
AST to be delivered almost immediately, and the routine can handle the AST and 
clean things up before routine exits?

Note, I do not write device drivers.  Lately most of this has been for socket 
communications.  And I'll use QIOW when I can, which is often.

I can imagine that device drivers might be a bit more unpredictable.