From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: re: $QIO: What happens within?
Date: 15 Dec 92 13:27:40 GMT
Distribution: world
Organization: The Internet


	What is the sequence of events when a qio is executed? In particular:

	I am using a $QIO to send data between mail boxes. I have a global
	structure which is updated at AST level by various tasks. When I get a
	request from  another program, I send the structure by qio, specifying
	the address of the actual global structure, rather than first making a
	copy.

	This is in FORTRAN so both the global structure and any local copies
	would be at some fixed location in memory and _NOT_ on the stack.

	Here is the question: Does $qio (not $qiow) make its own copy of the
	data  prior to returning, or does it just use the data at the memory
	location speced?

This is ENTIRELY up to the driver.  I/O requests in VMS can be handled in one
of two standardized ways:  Buffered I/O requests copy the data to and from a
system buffer, and from there to the I/O device, while direct I/O requests
move data directly from the I/O device to and from the user's virtual memory.
Almost all drivers use one or another of these methods, since VMS provides
routines for them that do all the dirty work.  However, a driver writer COULD
do anything he liked, with enough work.  For example, a clever driver for some
kind of network device might build a system-space buffer of header information
while moving the bulk of the data directly from user memory.  This wouldn't
be either buffered or direct I/O in the usual sense.

Even in the case of queued I/O, there is nothing in VMS that documents WHEN
the copy into system space takes place.  A driver, if it wished, could
allocate a system buffer and kick a data-mover routine running on another CPU
to fill it, returning to the calling program before the copy was complete.
Once you've called QIO, the buffer belongs to the I/O system until the I/O
completes, as signaled to you by the filling in of the IOSB.

In practice, I've never run across a driver doing buffered output operations
that did not finish copying the data before returning from $QIO; but that's
not a guarantee.

	Here is what I am worried about

	1) Stack frames: If I were doing this in Pascal or C and sent a local
	variable via qio. By the time the qio got around to actually sending
	the data, the routine that called the qio may have returned, the stack
	frame would no longed be valid and who knows what might be in the
	(stack) memory location that used to contain the data.

Could, theoretically, happen.

	2) The data in my case is updated by ast-level interrupt routines.
	What if the updating routine is executing when the $qio is ready to
	start shipping the  data. Will the qio interrupt the ast routine to
	ship the data? Does it matter if the qio was called at AST level or at
	"normal" level? Is it possible that the data will be corrupt due to
	incomplete updating of the data?

Again, in all drivers I've ever used, the data is copied by kernel-mode code
with SYS$QIO.  Hence, the AST cannot be delivered.  However, there are no
guarantees.

	Perhaps a milbox is a bad example because it is all memory. what if I
	was  sending large amounts of data down a slow serial line, using
	local  variables in a stack-frame language like pascal.

Both the mailbox driver and the serial line drivers use buffered I/O, and I
can tell you from both practical experience and perusal of the drivers that
the data WILL be fully copied before $QIO returns - as of the last time I
checked (which is several versions back, actually).  Will it remain like this
in the future?  Who knows!

If you want to write reliable, supportable code, you must not modify the
buffer until you know the I/O has completed.
							-- Jerry