As you are saying, there are two
different classes of errors here.
1) Keys which are not understood and
need to be ignored by functions which don’t grok them (“JIMS_SECRET_TAG”,”99”)
2) Keys which are understood by a
function, but with a value which is not (“buffer_size”, “Hello”)
I think allowing the second type to have
undefined behavior is the right thing to do, since it’s the most general.
If your implementation wants to define the
behavior of some out-of-range values, that’s fine and doesn’t make
you non-conforming, it just means you defined the previously undefined behavior
for some set of values.
Having that undefined-ness explicit here
(in one central place) seems to make sense (if only because it may be omitted
in one of the other places where it should appear).
My addition does not alter the existing
change which guarantees case 1, it’s only concerned with case 2.
-- Jim
James Cownie <[email protected]>
SSG/DPD/PAT
Tel: +44 117 9071438
From:
[email protected] [mailto:[email protected]] On Behalf Of Richard Treumann
Sent: 31 January 2008 14:20
To:
Subject: Re: [mpi-21] Ballot 4 -
Re: Request for interpretation
Jim -
I was taking the view that the description of what to do for a recognized key
but dubious value belongs to the function that recognizes the specific key. For
example if MPI_File_open accepts a "buffer_size" hint with range
"32K" to "16M" we may want to define the behavior of hints
that are out of range.
Once we say an info can have arbitrary keys we need to state that every info
consumer must be prepared to ignore keys it does not recognize because we have
made unrecognizable keys legitimate.
Dick
Dick Treumann - MPI Team/TCEM
IBM Systems & Technology Group
Tele (845) 433-7846 Fax (845) 433-8363
[email protected]
wrote on 01/31/2008 08:43:04 AM:
> However, you have apparently lost the liberty
to have undefined
> behavior which was there in the previous
version.
>
> Maybe
you should keep that, something like
> An
implementation must support info objects as caches for arbitrary
> (key, value) pairs, regardless of whether it
recognizes the keys.
> Each MPI function which takes hints in the
form of an MPI_Info must
> be prepared to ignore any key it does not
recognize. However if a
> function recognizes a key but not the
associated value, then the
> behavior is undefined.
>
(Modifications in italics)
> -- Jim
>
> James Cownie <[email protected]>
> SSG/DPD/PAT
> Tel: +44 117 9071438
>
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Richard Treumann
> Sent: 31 January 2008 13:29
> To:
> Subject: Re: [mpi-21] Ballot 4 - Re: Request
for interpretation
>
> Your
wording works for me Rolf. -- Thanks
>
>
> Dick Treumann - MPI Team/TCEM
> IBM Systems & Technology Group
> Dept 0lva / MS P963 --
> Tele (845) 433-7846 Fax (845) 433-8363
>
>
> [email protected] wrote on
01/31/2008 05:25:46 AM:
>
> > I try to summarize all 3 replies in one
proposal:
> >
> > ___________________________________
> >
> > Proposal:
> > MPI 2.0, Sect. 4.10 Info Objects, page
43, line 38-40 read:
> > 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.
> > but should read:
> > An implementation must support
info objects as caches for arbitrary
> > (key, value) pairs,
regardless of whether it recognizes the pairs.
> > Each MPI function which
takes hints in the form of an MPI_Info must
> > be prepared to ignore any
key it does not recognize.
> >
> > Add after MPI 2.0, Sect. 4.10 Info
Objects, page 44, line 22 a new
> > paragraph:
> > Advice to implementors.
> > Although in MPI functions
that take hints in form of an MPI_Info
> > (e.g., in process creation
and management, one-sided communication,
> > or parallel file I/O), an
implementation must be prepared to ignore
> > keys that it does not
recognize, for the purpose of MPI_INFO_GET_NKEYS,
> > MPI_INFO_GET_NTHKEY,
MPI_INFO_GET_VALUELEN, and MPI_INFO_GET, the
> > implementation must retain
all (key,value) pairs so that layered
> > functionality can also use
the Info object.
> > (End of advice to
implementors.)
> > _____________________________
> > Rationale for this clarification:
> >
> > The MPI-2.0 text allowed
that also MPI_INFO_DELETE, MPI_INFO_SET,
> > MPI_INFO_GET, and
MPI_INFO_DUP could ignore (key,value) pairs
> > that are not recognized in
routines in other chapters that
> > take hints with info
arguments.
> > The proposed clarification
is necessary when we assume, that
> > layered implementation of
parts of the MPI-2 standard should
> > be possible and may use the
MPI_Info objects for their needs.
> > This was a goal of the
MPI-2 Forum and the MPI-2.0 specification.
> > ___________________________________
> >
> > Bronis, for me, your wording "an
MPI implementation may restrict" was
> > in conflict with the rest of the advice.
I hope the formulation above
> > is also okay. It is based on the new
wording from you and Dick in first
> > part of the proposal.
> >
> > Best regards
> > Rolf
> >
> >
> > Dr. Rolf Rabenseifner . . . . . . . . .
.. email [email protected]
> > High Performance Computing Center (HLRS)
. phone ++49(0)711/685-65530
> >
> > Head of Dpmt Parallel Computing . . .
www.hlrs.de/people/rabenseifner
> > Nobelstr. 19, D-70550
> >
_______________________________________________
> > mpi-21 mailing list
> > [email protected]
> > http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
>
---------------------------------------------------------------------
> Intel Corporation (
> Registered No. 1134945 (
> Registered Office:
> VAT No: 860 2173 47
>
> This e-mail and any attachments may contain
confidential material for
> the sole use of the intended recipient(s).
Any review or distribution
> by others is strictly prohibited. If you are
not the intended
> recipient, please contact the sender and
delete all copies.
>
_______________________________________________
> mpi-21 mailing list
> [email protected]
> http://lists.cs.uiuc.edu/mailman/listinfo/mpi-21
--------------------------------------------------------------------- Intel Corporation (UK) Limited Registered No. 1134945 (England) Registered Office: Pipers Way, Swindon SN3 1RJ VAT No: 860 2173 47 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.