[Info-vax] QIO Writes to a mailbox

[Richard B. Gilbert]

On 11/9/2011 9:18 AM, VAXman- @SendSpamHere.ORG wrote:
> In article<531039d1-7923-4751-81ad-ec707d299aec at u28g2000yqb.googlegroups.com>, Steve Bainbridge<stephen_bainbridge at yahoo.co.uk>  writes:
>> {...snip...}
>>
>> 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.
>
> If I were you, I wouldn't hire that "programmer" write any multi-threaded
> applications for you! :)
>
>
>
>> 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.
>
> Assuming what you say about the buffer and IOSB, you can simply malloc()
> enough memory to maintain the IOSB (2 longwords) and the buffer, copy the
> data into the buffer and then, pass those addys along to the $QIO.  Pass
> the addy of what you've malloc()ed as the ASTPRM, so that an AST can both
> check the IOSB and free() memory.
>
> The general rule of thumb should be, never ASSUME (there's an Oscar Wilde
> quotation WRT) anything until the status is available in the IOSB.
>
> If it's the MOST critical module in the system, shouldn't it be written
> as if it's the MOST critical module in the system?  Attaching modifiers
> to the IO$_WRITEVBLK might appear to fix your current issue but they're
> not going to fix the problem of improper coding WRT the $QIO/IOSB/AST.

Some people are extremely slow to learn.  There are far more EASY ways 
than there are RIGHT ways!  If the business is, in any way, dependent on 
this system, someone had better take charge and make CERTAIN that it's 
being done RIGHT!!!!!!

If VAXman is too busy or uninterested, I'm available!