[Info-vax] QIO Writes to a mailbox

[JF Mezei]

Johnny Billquist wrote:
>
> Do a QIO to a serial port, then change the buffer, and then sit and 
> watch what you actually get as output. 

I am talking specifically about the mailbox driver which is an in-memory
construct.  The serial driver cannot instantly deliver the data since it
may be forced to send bits out the serial port at 100 baud, and even an
all mighty Microvax II was able to go faster than that.

However, in the case of the mailbox driver, there is an in-memory buffer
 that belongs to the mailbox. Messages are queue there to be delivered
by whoever reads the mailbox.

It is entirely possible that during the QIO call, the driver queues the
request by moving the data to the mailbox buffer.


You should note that if a process writes to a mailbox and then crashes,
the reading process still gets the message despite the writing process
having died before the message was read. Thus would indicate to me that
messages are written to the mailbox buffer quickly and stay there.


If the driver merely copies from the writer's user buffer to the
reader's user buffer, then a maibox would not need to have its own
buffer size sepcified, would not be able to contain multiple messages in
that buffer.

More importantly, since a process can die gracefully between the time it
has done the write QIO and the time some other process has read the
mailbox message, it would indicate that the driver does not "lock" the
writer's user buffer by forcing a crashing process into RWAST to ensure
that when the reading process finally reads the message that the driver
woudl still have access to the writer's user buffer.

In other words, because a process can die gracefully and any unread
mailbox message it wrote before dying are preserved and still delivered,
the odds point to the driver making an immediate copy of the contents to
the mailbox buffer (aka: queues the io).

And this is why processes go into RWMBX when the mailbox buffer is full
since the driver is unable to write to the mailbox device until a
process reads some data from it to free up space in the mailbox's buffer.


Note that my experience is with QIOW with IO$M_NOW for writes to
mailbox, and I assume that the DCL WRITE statement does the equivalent
when writing to a mailbox device because they behave the same. And note
that a DCL WRITE to a full MAILBOX does cause the process to hang in RWMBX.


Since the $QIO system service doesn't know what "IO$M_NOW" means, the
different behaviour would be the result of the mailbox driver taking
actions during the initial QIO.  And since the portion of the driver
involved in responding to SYS$QIO has the ability to copy the user
buffer into the mailbox buffer when IO$M_NOW is specified, it is a good
bet that it copies it for all write operations, and that IO$M_NOW simply
means that the IO is considered complete when it is queued to the
mailbox with no notification pending for when a reader has read that
specific message later on.