[Info-vax] QIO Writes to a mailbox

[Johnny Billquist]

On 2011-11-10 00.21, JF Mezei wrote:
> Bob Koehler wrote:
>
>>     However, the behaviour inside the driver is not part of a documented
>>     API and could change with the next minor patch you install.
>
>
> Generic question about all write operations with QIO:
>
> There are generally 2 write option codes. IO$M_WRITEVBLK and another one
> whone nomenclature escapes me at the moment. Would those made a formal
> "documented" behaviour with regards to garanteed copying of the user
> buffer into a driver/device buffer during the SYS$QIO ?

No. The operation don't matter. QIO basically don't guarantee anything, 
as far as buffers are concerned. You should *never* touch a buffer 
before the I/O as completed. It is very simple.

And as far as write I/O operations goes, you have WRITEPBLK, WRITELBLK 
and WRITEVBLK. For some devices, they do exactly the same thing, while 
for some devices, they do totally different things.

And unless you know what you are doing, you most likely want WRITEVBLK 
all the time.

(It's physical, logical and virtual I/O, by the way, and it makes a 
difference for disks for instance.)

> Now, for a non generic question about TCPIP :
>
>
> Consider TCPIP. When you write data, you are not garanteed that this
> data goes out in its own packet. It may be combined with some previously
> issued writes or may wait until there are other writes made. Doesn't
> that behaviour pretty much require that the driver make copies of the
> data in its internal buffers so that you can then reuse your own buffer
> to issue subsequent writes ? (which allows the driver to then combine
> writes to make larger more efficient TCP packets) ?

Certainly.
But the I/O will indicate that it has completed when the data have been 
copied to the internal buffer, at which time you can reuse your I/O 
buffer. The I/O does not indicate that the I/O have been sent out, 
acknowledged, read by the other end, or anything even close to that.

So the same rule still applies. You do not know exactly when the driver 
will be reading the data from the program buffer into the internal 
buffer for TCP.
It's all really simple. Do not touch the buffer until the I/O is 
complete. And I/O is complete when you have a result code in the IOSB. 
You do not need to poll the IOSB, but can instead check if when the 
event flag indicates so, or when the AST have triggered.

	Johnny