[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-04 18.50, JF Mezei wrote:
> When the mailbox is created, it is given a buffer size.
>
> QIO will copy your data to that buffer right away even if there is
> nobody at the other end to read it.  QIOW will do the same.

No. This is not correct. QIO, as well as QIOW will not copy the data 
before returning from the system call. As the name implies, it *queues* 
the I/O request. It does not process it. The processing is then done by 
the driver, as it dequeues the request. It might buffer it, it might 
write directly from memory to a device. But if the device is currently 
blocked, the I/O request might not even be looked upon for quite a while.

> However, if there is nobody reading messages, the buffer will fill up,
> at which point both QIO and QIOW will hang in a RWMBX state because they
> cannot write to the mailbox device. They will unhang when someone reads
> the messages.

Exactly. So, you do not know when the data will be copied from your 
buffer. It might be quite a while between the queuing of the I/O request 
and the copy. If you do a QIOW, your program will not continue until the 
I/O is actually completed, and at that point it is safe to modify the 
buffer. But after a QIO, you cannot touch the buffer, or be prepared to 
face potential strange "errors". The buffer should not be touched until 
the I/O is complete.

> If a message sporadically gets lost, it could be because someone else
> has read it. (for instance, I could use DCL to OPEN myfile MBA9827: and
> then issue a READ myfile mybuffer and wait for it to complete. This will
> "steal" a message from the mailbox and your application will never see it.

Right. But if the message sometimes gets garbled, it might be that 
someone is writing to the buffer before it has been copied from the 
process space.

> Another possibility is that your receiving application has a bug in it
> and does get the message but doesn't process it. You will need to look
> at it very carefully to see if strange timing of events might cause this
> to happen. (for instance, upon receiving the message, your app thinks it
> has already processed it and discards it and issues a new read). Or in
> some circumstances, your program may reach a rarely used portion of code
> where there is also a QIO read of the mailbox and it gets that message
> which your mainline program will never get.
>
> (consider a case where some obscur message type causes your program to
> branch to a different subroutine which expects a second mailbox message
> to arrive).

There are so many fun ways things can go wrong when you are sloppy, indeed.

	Johnny