Re: comments on I/O chapter

Bill Nitzberg (nitzberg@nas.nasa.gov)
Mon, 14 Apr 1997 18:27:56 -0700

I have made most of Steve's corrections. Below is commentary
on some which could possibly change meaning.

- bill

In message <199704102343.SAA14804@rap.cs.wisc.edu> Steve Huss-Lederman writes
>
> 205/23-25: The two phrases, "beginning of a file" and "relative to the
> default view" are confusing me about what displacement is.

You're right; it is confusing. Since it was meant to be helpful,
rather than definitional, I have removed the second sentence:
"A displacement is an offset relative to the default view (see below)."

> 207: I think having words saying that all errors from MPI_OPEN are
> raised on the comm would be a good idea. I am thinking about errors
> that might happen after the fh is formed that some implemenation might
> choose to raise on fh instead of comm.

Added:
Errors which occur during \func{MPI\_OPEN} are raised on
the global file handle \const{MPI\_FILE\_HANDLE\_X}.

> 208/27-9: I assume the restriction that no concurrently opened for
> MPI_UNIQUE_OPEN includes another program/shell. If so it might be
> nice to clearly warn the user since external events can cause
> unexpected behavior.

Added:
\begin{users}
For \const{MPI\_UNIQUE\_OPEN}, {\em not opened elsewhere}
includes both inside and outside the \MPI/ environment. In
particular, one needs to be aware of potential external events
which may open files (e.g., automated backup facilities). When
\const{MPI\_UNIQUE\_OPEN} is specified, the user is responsible
for ensuring that no such external events take place.
\end{users}

> 210/36: I think it would be good to define what happens if the
> MPI_FILE_SET_SIZE fails because the impl. cannot deal with it.

I left this alone; like so many error conditions in MPI, we have
ignored this. If someone wants to suggest some error text, I will
be happy to add it.

> 212/32: says example "portably decoding" but the code has a "MAXBITS =
> 30". I think it isn't truely portable.

I left this alone; any takers for a portable re-write?

> 214/45+: all the key values (e.g., read_once, etc) seem to have use
> the key macro so they show up in info key appendix. They aren't
> really keys but constants that the key value can use. I think the
> macro needs changing (or maybe a new one added).

Changed the macro to use \constskip{} rather than \const{}

> 216/23: fh is listed as IN for MPI_FILE_SET_VIEW. What I am wondering
> is if it should be INOUT. Clearly the values pointed to in fh are
> modified. Unlike some of the other cases recently debated, user
> visible values are involved. If this idea is accepted it effects lots
> of rouintes in this chapter. It may alos effect other routines in
> other chapters so we need to make a global decision.

Here is the current list of routines which accept file handles
and the current binding and "new" proposed binding for fh:

Routine Old fh New value (if different)
---------------- ------ ---------
MPI_OPEN OUT
MPI_CLOSE INOUT
MPI_FILE_SET_SIZE IN INOUT
MPI_FILE_PREALLOCATE IN INOUT
MPI_FILE_GET_SIZE IN
MPI_FILE_GET_GROUP IN
MPI_FILE_GET_AMODE IN
MPI_FILE_SET_INFO IN INOUT
MPI_FILE_GET_INFO IN
MPI_FILE_SET_VIEW IN INOUT
MPI_FILE_GET_VIEW IN
MPI_READ_EXPLICIT IN INOUT
MPI_WRITE_EXPLICIT IN INOUT
MPI_IREAD_EXPLICIT IN INOUT
MPI_IWRITE_EXPLICIT IN INOUT
MPI_READ IN INOUT
MPI_WRITE IN INOUT
MPI_IREAD IN INOUT
MPI_IWRITE IN INOUT
MPI_SEEK IN INOUT
MPI_FILE_GET_POSITION IN
MPI_FILE_GET_BYTE_OFFSET IN
MPI_READ_SHARED IN INOUT
MPI_WRITE_SHARED IN INOUT
MPI_IREAD_SHARED IN INOUT
MPI_IWRITE_SHARED IN INOUT
MPI_READ_SHARED_ORDERED IN INOUT
MPI_WRITE_SHARED_ORDERED IN INOUT
MPI_SEEK_SHARED IN INOUT
MPI_FILE_GET_POSITION_SHARED IN
MPI_FILE_GET_TYPE_EXTENT IN
MPI_FILE_SET_ATOMICITY IN INOUT
MPI_FILE_GET_ATOMICITY IN
MPI_FILE_SYNC IN INOUT
MPI_FILE_SET_ERRHANDLER IN INOUT
MPI_FILE_GET_ERRHANDLER IN

> 220/34+: It seems to say _ORDERED is just like non-ordered but
> collective. This is true for _ALL but _ORDERED also imposes a
> specific sequential order.

I propose we delete most of this section 10.4.1, see note in
response to Rajeev's comments.

> 221/34: I think the cancelled field in status may also have to be
> filled in. It seems that one should be able to test this since I
> assume I/O operations can be cancelled. If true effects later text too.

Added:
If the data access operation was cancelled,
the \funci{MPI\_TEST\_CANCELLED} routine will
return \mpiarg{flag = true}.

> 221/38,222/37,225/13,226/2: The language neutral part of the function
> definition is missing in all 4 of these places.

This is intentional---they are identical to those above, and do
not need to be repeated. (Unless you have macros that require them?)