From: Raja Daoud <raja@XXXXXXXXXXXXXXX>
Subject: Re: Request for interpretation
To: linda@XXXXXXXXXXX
Date: Fri, 18 Jun 1999 15:09:02 CDT
Cc: mpi-core@XXXXXXXXXXX,treumann@XXXXXXXXXX
In-Reply-To: <199906181535.IAA13597@XXXXXXXXXXX>
Reply-To: raja@XXXXXXXXXX
X-Mailer: Elm [revision: 112.8]
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: d15c8b3a55b76362a3d51ecc7f029ec5


> The IBM implementation of MPI_Info is, in my opinion, extending the
> semantics of MPI_INFO_SET and MPI_INFO_GET beyond what the standard says.
> I do not find in the specifications of these functions that they are
> supposed to behave as filters to determine what hints are accepted or
> to modify the values associated with keys that are recognized, nor to
> behave in the way that MPI_FILE_GET_INFO was intended to provide feedback
> on which hints were recognized/effective for a given file.

I think the point to resolve is to decide what this sentence means:

"If a function does not recognize a key, it will ignore it, unless
otherwise specified.  If an implementation recognizes a key but does not
recognize the format of the corresponding value, the result is undefined."

(I don't have the page/line reference, it's in
www.mpi-forum.org/docs/mpi-20-html/node53.html).


Does "function" include MPI_Info_set() or not?  If it does, IBM's
implementation is valid (and actually provides additional value to
users).  I think it doesn't follow the spirit of MPI_Info as I remember
it from the Forum meetings (i.e. users wanting and winning the vote
for MPI_Info to be a glorified bucket of key/value strings).

If "function" only refers to the routines that interpret/consume the
info keys, then filtering is not allowed and MPI_Info has to keep track
of all strings in order.  Note that it can in addition, under-the-table,
compile an optimized/filtered representation for faster use by the
consuming routines, but that representation would not be used by the
MPI_Info_* retrieval functions.


I don't have a strong feeling on this one.  The handling of recognized
keys is a benefit to implementations, and it is not in dispute.  The
handling of unrecognized keys or invalid values is mostly a service to
users.  We have two valid ways to handle that case, and both provide
some value but take away another (layerability vs. more visibility into
an implementation's internal parameters).

Which of these two approaches does the majority of users prefer to have,
or do you prefer to allow both to be valid?

--Raja