Date: Tue, 22 Jun 1999 09:58:49 -0700 (PDT)
From: Linda Stanberry <linda@XXXXXXXXXXX>
To: treumann@XXXXXXXXXX
Subject: Re: Request for interpretation
Cc: mpi-core@XXXXXXXXXXX
Sender: owner-mpi-core@XXXXXXXXXXX
Precedence: bulk
X-UIDL: 2e4a10efa23e50e66500ca7483b4cc0b

Dick,

> Several people have suggested that MPI_Info should be a general purpose string
> pair cache.  There are a couple things which I think would have been appropriate
> if that were true.
>
> 1) MPI_GREQUEST_START should take an info.  It takes only an "extra_state".
> 2) The MPI_objtype_SET_NAME/GET_NAME functions could have been
>    MPI_objtype_SET_INFO/GET_INFO functions with a predefined "name" key.

The MPI_Info specification was consolidated from the three current subsets
of MPI-2 that use Info objects rather late in the standards process.  The
generalized request spec underwent fairly substantive revisions right down
to the final draft of the standard as well.  At least, these were my 
observations as an early "user" of the MPI-2 specification, attempting to
implement MPI-IO even as the standard was in such flux.  Given more time
to recognize the general utility of the key-value pairing, the standard
may have considered these as appropriate; or not.

> MPI created extra_state and attribute caching as unconstrained methods for
> stashing
> and retrieving information. I think much of the value of Info objects is in
> the ability of the implementation to understand the operations a user may
> attempt
> and give meaningful feedback.

Seems to me an Info object could be passed as the extra_state, or part of the
extra_state, of a generalized request since no type restriction is imposed.
Similarly, it might be useful to cache an Info object as an attribute.
However, with your proposed interpretation of Info objects, this would
be pointless since arbitrary (general purpose) pairings are not allowed, so
the potential utility of Info objects to new uses such as these is nil.

> <snip>
>
> >
> >  Additionally I would say that the sentence "If a function does not
> >  recognize a key, it will ignore it, unless otherwise specified"
> >  does not say >>if a function does not recognize a key, OTHER FUNCTIONS
> >  [e.g. MPI_INFO_SET] can ignore it<<.
>
> This language about ignoring keys is part of the section about creating and
> accessing info objects, notpart of the sections on functions to which info
> objects are passed.  MPI_INFO_SET/INFO_GET etc. are the proximate functions
> to this statement.
>
> I do agree one intent of MPI-2, and probably of this statement, is that
> MPI_FILE_SET_INFO etc will tolerate a key:value which is intended for spawn.
> It is not clear that is the only intent.

Since the language about ignoring keys is repeated at the points of use
of MPI_Info objects as arguments, with specifics about the reserved keys
appropriate for those uses, I originally thought the wording in 4.10 was
superfluous and probably an oversight due to the consolidating of the Info
specification from earlier diverse specs.

It seems to me that an implementation _must_ do the checking of keys at
the point of use, not the point of creation, since there is no guarantee
that a purported MPI_Info handle has been constructed correctly.  (For
example, what if I've supplied my own layered implementation of Info
objects?)

Others who have commented on the discussions at the Forum meetings have
not seen this language as restricting what key-value pairs could be
associated through calls to MPI_INFO_SET.  It was certainly not my 
impression that this should be the case upon reading 4.10.  If this were
the intended interpretation, I would expect the spec of MPI_INFO_SET to
require an error return if the key were unrecognized or if the value
were out of range.  Instead, your proposed implementation quietly fails,
or changes the value associated with a key, and this is of no assistance
to a user, IMHO.  Each use of MPI_INFO_SET must be followed by a call of
MPI_INFO_GET in your model, to determine whether or not a key was accepted,
and if so, what value was really associated with it.  I certainly do not
see this intent in the specification or Advice for these functions in
4.10.  The only imposed constraints I see there on key/value strings are
on the length of such strings.

> <snip>
>
> >
> >  "This function retrieves the value associated with key in a previous
> >  call to MPI_INFO_SET."
> >
> >  I do not see >>CAN retrieve<<, I see >>RETRIEVE<<.
> >

> "association" is an operation on the MPI_Info object which the standard
> fails to define carefully.  Note that the sentence doe not say "The value
> the user provided".   In "signed char cc; cc = 129;"  what is the value
> associated
> with cc?

If the question is, for:

	MPI_Info_set(&myinfo, "signed char cc", "129");

What should be returned for:

	MPI_Info_get(myinfo, "signed char cc", len, &myvalue, &found);

I think found should be TRUE and myvalue should be "129", provided len
is >= 3.  If len <= 2, found should be TRUE, but myvalue will be
truncated.  (If MPI_MAX_INFO_KEY is 10 or len > MPI_MAX_INFO_VAL, the
call should return an appropriate error.)

But I'm worried about what an implementation may be allowed to return
if the model allows changing the value associated with the key to
something other than what the user provided.  Is an implementation
allowed to return "Not a number" or "blue" or ???

> I consider the issue to be between having a defined interface that users can
> work with effectively and having a third kind of bucket for layering which will
> frustrate the heck out of MPI users.

Well, I consider myself to be a user.  I tried to use MPI_INFO_SET to 
implement the MPI_FILE_GET_INFO functionality in an implementation of
MPI-IO to be layered over the IBM implementation of MPI-2.  I was quite
dismayed when I found that I couldn't construct the Info object to be
returned by MPI_FILE_GET_INFO with MPI_INFO_SET.  I had checked the
return value of MPI_INFO_SET, and it was MPI_SUCCESS.  I was dismayed
and continue to be frustrated that this is supposed to be helping me
as a user of MPI-2.  I am prevented from effectively using the IBM
implementation of Info objects, so I am forced to layer my own version
of Info objects to be effective.  But I worry about applications that
will use both MPI-IO and MPI_WIN_CREATE or MPI_COMM_SPAWN:  will the
Info objects they create with my MPI_INFO_SET implementation be 
effective...and safe...with the underlying MPI-2 implementations?

Linda