[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-06 05.07, Michael Moroney wrote:
> JF Mezei<jfmezei.spamnot at vaxination.ca>  writes:
>
>> Michael Moroney wrote:
>
>>> It works as you state if and only if you specify the IO$M_NOW modifier.
>>>
>>> Without it, writes will wait until another process issues a read for the
>>> same data.
>
>
>> But doesn't mean that the data in the user's buffer is not copied to the
>> mailbux device's buffer where it is queued for delivery.
>
>> It only means that the IO is not deemed complete until that message has
>> been read from the mailbox.
>
>> Since mailbox devices are FIFO devices capable of holding multiple
>> messages (depending on the declared buffer size and size of messages),
>> wouldn't the QIO immediatly want to claim its position in the mailbox
>> buffer and queue the message for delivery right away, and then wait (if
>> not IO$_M_NOW) for the message to get to the head of the queue and then
>> read ?
>
>
> I honestly don't know for sure when the buffer is copied, and if it is
> copied before the read (I think it is) I don't know whether a $QIO is
> guaranteed to not resume execution to the calling routine before the
> buffer is copied.

You are never guaranteed that the buffer is copied before the QIO 
returns. How hard can it be to understand? The QIO is a system call, not 
an I/O operation. The only things that are guaranteed to have happened 
before the QIO return is that all parameters are verified to be 
reasonable. The event flag have been cleared. The IOSB have been 
cleared. That's it. The system call does not know exactly what I/O 
operation is requested. Only that it is a valid I/O operation for the 
device. The driver, to which the I/O is requested, can have some 
pre-queuing hooks, which will be called as a part of the system call 
setup, but that is rather optional. Then the system queues the request 
to the driver, and the system call is done. Unless it is combined with a 
WAIT, the process will then continue, while the I/O will happen 
asynchronously to this.
It is the driver that does data copying. Not the kernel as such.

Depending on your machine, and so on, this can easily be demonstrated. 
Do a QIO to a serial port, then change the buffer, and then sit and 
watch what you actually get as output. With todays fast computers, with 
very fast devices, it can be harder to get a setup where you easily can 
see this.
(It can better be demonstrated by issuing two QIO in quick succession, 
where you change the buffer of the second QIO after the QIO have been 
done, since that will make sure that the driver have not started 
processing the I/O request before you have time to modify the buffer.)

	Johnny