[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-09 23.40, Jan-Erik Soderholm wrote:
> VAXman- @SendSpamHere.ORG wrote 2011-11-09 17:53:
>> In article<j9e29r$uud$1 at news.albasani.net>, Jan-Erik
>> Soderholm<jan-erik.soderholm at telia.com> writes:
>>> VAXman- @SendSpamHere.ORG wrote 2011-11-09 14:34:
>>>> In article<j9dpir$vs2$1 at dont-email.me>, Albrecht
>>>> Schlosser<vms-news at go4more.de> writes:
>>>>> On 08.11.2011 22:36, VAXman- @SendSpamHere.ORG wrote:
>>>>>> In article<j9c6ug$r1s$1 at news.albasani.net>, Jan-Erik
>>>>>> Soderholm<jan-erik.soderholm 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.
>>>>
>>>> Didn't I say: "specify the IOSB, check it and assume nothing!"?
>>>> Ignoring
>>>> the IOSB may just be the "tip of the iceberg" but it's a starting
>>>> point.
>>>>
>>>
>>> We hear you. I never wrote that one should *ignore* the IOSB.
>>>
>>> My point was to delay the check of the IOSB so that you don't
>>> spend time waiting when you could have done something more
>>> productive in your app instead. If it *is* asyncronious, that
>>> is so you could go on doing other stuff while the I/O complets.
>>
>> That's what the AST is for. It's fired as part of the I/O's completion.
>>
>
> 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.

> This is common logic for any programmning. If you do anything that takes
> some times and that you have to wait for, wait (if neeed) *before* you do
> the call, not after. That way you do not wait if it's not needed.

Well, yeah, you could put it that way. It does take some extra setup at 
startup though, so you don't fail already at the start. Much nicer with 
ASTs really.

	Johnny