[Info-vax] QIO Writes to a mailbox

[abrsvc]

On Nov 6, 6:15 pm, Johnny Billquist <b... at softjar.se> wrote:
> On 2011-11-06 23.42, Johnny Billquist wrote:
>
> > On 2011-11-06 23.07, Johnny Billquist wrote:
> >>> 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).
>
> >> Remove the word "immediately", and I agree with all you write.
>
> See VMS Programming Concepts Manual, section 3.2.1.4 - Asynchronous I/O.
> That pretty much lays it out clear that the I/O operation is not
> conceptually completed as a part of the QIO, and that the data is copied
> asynchronously in relation to your program.
>
>
>
>
>
> >>> 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.
>
> >> If you do a QIOW with IO$M_NOW, then you should never get to RWMBX
> >> state. Nor will you ever have a situation where your program can
> >> potentially have a buffer that is yet not copied into the mailbox, but
> >> soon might be. IO$M_NOW ensures that if the mailbox is full, the QIOW
> >> will complete the I/O with an error saying that the mailbox was full,
> >> and the I/O could not be completed. The QIOW itself blocks your program
> >> from ever continuing until the I/O has completed.
>
> >> There is a big difference between QIO and QIOW!
>
> >> A DCL write will most likely always be a QIOW.
>
> > Also, I might have been slightly confused by the IO$M_NOW. Unless my
> > memory fails me now, that modifier will guarantee that your write does
> > not complete until the message have been read by someone.
>
> Aw! Crap! Wrong again. It was the other way around. Without the
> IO$M_NOW, it would wait. With it, it continues and complete the I/O
> regardless of if a reader have read the message or not. Ok, I hope this
> is my last correction on this section. :-)
>
> So yes, the IO$M_NOW means you can get to the RWMBX state, even when
> using QIOW. I suspect it is equally possible to get to RWMBX without the
> IO$M_NOW, if you use QIO instead of QIOW.
>
> >>> 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.
>
> To make another comment here - Your comment don't make sense to me. Of
> course the different behavior is originating from inside the device
> driver. However, your conclusion that it therefor happens during the
> queuing of the I/O is totally unfounded. It does not happen during the
> initial QIO. The IO$M_NOW modifier affects what happens when the I/O is
> completed, not what happens when it is initiated. All that happens
> during the QIO phase is that parameters are checked for basic sanity,
> basic setup, and then the I/O is queued to the device driver. At this
> point, the QIO returns execution to the process, with a result in R0 for
> the system call, while the IOSB is zero (operation is pending). If you
> do a QIOW, execution does not return to your process until the I/O is
> complete, at which time you will have both R0 containing the result of
> the system call, and the IOSB containing the result of the I/O.
>
> I agree that it is a good bet that the mailbox driver copies the data
> for all operations, in fact, reading manuals more or less says that it
> does. But it don't really say *when* it happens.
>
> The IO$M_NOW is only affecting when the I/O is signaled as complete.
> Either when the data have been copied into the mailbox, or when the data
> then also have been copied out into the buffer of a read I/O request.
> All of that happens in the device driver, as a part of the I/O
> processing, and is generally not happening in the context of the
> requesting program, but in a kernel thread.
>
> (Now, in reality, for mailboxes, I would guess that there is no need for
> a kernel thread, since all that is involved is actual data copying, and
> therefore no kernel thread is needed since it really becomes rather
> synchronous, since it's all depending on the CPU anyway. And the normal
> next step after queuing an I/O request to a device driver, is to wake up
> the device driver, to make it pick up any possible work, I wouldn't be
> surprised if the end result is that a QIO and QIOW becomes identical in
> the case you add the IO$M_NOW modifier, since the I/O will in fact be
> completed immediately, if space exist. But that is a very peculiar side
> effect of the specific driver in a specific mode, and does not fairly
> reflect on how QIO is actually processed by VMS, and it would appear it
> might make people draw the wrong conclusions about what the QIO system
> call actually do.)
>
>         Johnny- Hide quoted text -
>
> - Show quoted text -

According to the docs, your statement above is not 100% correct:

The modifier: IO$M_NORSWAIT must be set in order to return the MBFULL
status.  Otherwise, the process will wait until space becomes
available.  The IO$M_NOW determines whether the "queueing" completes
immediately or not in regards to the opposite function.  In
otherwords, when writing wait for the read or when reading wait for a
write.  WIth the IO$M_NOW enabled, the QIO will complete WITHOUT
waiting for the companion read/write.

Please note also that the IO$M_RSWAIT will NOT affect other potential
resource waits that are not mailbox full waits.  It is still possible
to get resource waits with this set, just not for a full mailbox.

Dan