[Info-vax] QIO Writes to a mailbox

[Steve Bainbridge]

On Nov 9, 11:52 am, Albrecht Schlosser <vms-n... at go4more.de> wrote:
> On 08.11.2011 22:36, VAXman- @SendSpamHere.ORG wrote:
>
> > In article<j9c6ug$r1... at news.albasani.net>, Jan-Erik Soderholm<jan-erik.soderh... at telia.com>  writes:
> ...
> >> One efficient way to do it is to check the previous IO (say, by
> >> checking the IOSB) right *before* you will do the *next* $QIO.
> >> In that way, you can do any other processing you like in your
> >> app while the I/O subsystem completes the IO asyncronicaly.
>
> >> Always waiting right *after* the $QIO is inefficent and you could
> >> anyway use $QIOW and let the system take care of the "waiting".
>
> > Even when using $QIO and an AST, one needs to check the IOSB.  Like I said,
> > specify the IOSB, check it and assume nothing!
>
> Yep, that's true, of course, but may not be sufficient in
> Steve(the OP)'s case. He did not write anything about how
> often mailbox writes are generated (maybe asynchronously)
> in the writer program.
>
> If we assume that he reuses buffers (as well as the IOSB),
> then it might be possible to overwrite one message with the
> next message, so that two consecutive QIO's will send the
> same message to the mailbox. I know, this has already been
> said, but it should be considered as a possible cause of
> errors too. Thus, the reader process might read one message
> twice, and - depending on the processing in the reader
> process - may not realize the duplicate, and also miss the
> overwritten message. This *could* explain what Steve is
> seeing, even if all I/O's were working correctly (QIO and
> IOSB success).
>
> Jan-Erik's idea to check the previous IOSB value just
> before the next I/O might help, if the code also makes
> sure that the I/O buffers are written *after* the check.
>
> Of course, it would be better not to overwrite I/O buffers
> and to use different IOSB's as long as it is possible to
> do asynchronous writes to the mailbox in the first place.
>
> I'd check this possible overwriting as well as the IOSB
> return value, especially if all messages are of the same
> sizes (so that overwriting the buffer contents wouldn't
> be so obvious).
>
> Albrecht

Albrecht,

The buffer and IOSB are declared as static at the beginning of the
routine and there is only one of them. The routine is called
asynchronously, triggered by incoming messages - there could be a
burst of messages in a very short space of time which may highlight
issues of buffer re-use/corruption.

Depending upon who you believe QIOs may or may not copy the data
buffer before it returns - several people have said that mailboxes use
buffered IO and the buffer is copied before it returns from the QIO.
Everyone seems to agree that this is implementation specific and you
can't rely upon it always being the case.

I've since had a chance to look at more detail at this module and I've
found about 15 similar cases of QIOs being used with single buffers -
all don't bother to check the IOSB. I'm reluctant to make wholescale
changes to the module as it's the most critical module in the system
and testing will be a significant challenge. I'm considering changing
the QIO to be a QIOW with the modifiers IO$_WRITEVBLK, IO$M_NOW and IO
$M_NORSWAIT. Naturally checking the return code and IOSB return code.
This should allow me to keep the single buffer, but also highlight if
the process cannot immediately queue the data.

Steve