[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-05 05.14, JF Mezei wrote:
> Johnny Billquist wrote:
>
>> No. This is not correct. QIO, as well as QIOW will not copy the data
>> before returning from the system call.
>
> QIOW by definition waits for an event flag to be set to signal that the
> IO has completed, so this garantees that the buffer has not only been
> copied, but also been written in full to the mailbox device.

Right. I don't know what I was thinking here. A QIOW will not return 
until the whole I/O is completed. Temporary lapse of reason.

> I've always used QIOW to write to mailbox devices. (but QIO to read from
> them with AST routines etc).
>
> But when QIO executes, doesn't it invoke some driver code to "queue" the
> IO, and isn't it possible that for a write to memory device, that drive
> code might actually do the write to the mailbox device ?

It is possible for drivers to have pre-queueing hooks invoked. Those 
could in theory also copy the data somewhere. But you don't know that 
for sure, so unless you have some very intimate knowledge of the exact 
driver you are calling with the QIO (and that also assumes that you make 
sure that your I/O is not redirected somewhere else causing it to go to 
another driver you might not know about), you better assume that the 
buffer is not copied before the I/O is queued. The ability to buffer the 
data also depends on there being enough free resources. This might not 
always be the case, in which case the driver can't buffer anyway. In 
short, don't ever make the assumption that the driver will buffer, and 
especially not even before the QIO have been processed by the driver, 
which happens asynchronous to your system call.

> And if a mailbox is full, I know that QIOW will cause process to hang on
> a RWMBX, but would a QIO also result in this ?

I would be very surprised, since that would break the general 
asynchronous paradigm of a QIO.

	Johnny