<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Richard Treumann wrote:
<blockquote
cite="mid:OF53A2ED6B.B707548F-ON852577A6.00422ED4-852577A6.0047BF89@us.ibm.com"
type="cite"><br>
<font face="sans-serif" size="2">This proposal is not a minor change.</font>
<br>
<br>
<font face="sans-serif" size="2">Please do not make this hole in the
standard and assume you can later add language to standardize
everything
that comes through the hole.</font>
<br>
<br>
<font face="sans-serif" size="2">If the standard is to introduce the
notion of a recoverable error it must be as part of a full description
of what "recovery" means. </font>
<br>
<br>
<font face="sans-serif" size="2">I think is is dangerous and
ultimately
useless to have implementors mark a failure as "recoverable"
when the post error state of the distributed MPI has gone from "fully
standards compliant" to "mostly standards compliant, read my
user doc read my legal disclaimer, cross your fingers".</font>
<br>
<br>
<font face="sans-serif" size="2">See comment below for why I do not
think
the new hole is needed to allow people to do implementation specific
recoverability.</font>
<br>
<br>
<font face="sans-serif" size="2">There is not even anything to
prevent
on implementation from deciding to add a function
MPXX_WHAT_STILL_WORKS(err_code,
answer) and documenting 5 or 5000 enumerated values for "answer"
ranging from NOTHING through TAKE_A_CHANCE_IF_YOU_LIKE to EVERYTHING.</font>
<br>
<br>
<font face="sans-serif" size="2">IBM would probably return
TAKE_A_CHANCE_IF_YOU_LIKE
because I cannot imagine how we would promise exactly what will work
and
what will not but in practice most things will still work as expected.
</font><br>
<br>
</blockquote>
I think I agree with Dick on the above. Another way of putting the
disagreement is that Josh's proposal is too general in that not all
errorcodes can be completely marked as MPI state is broken or not.
When Sun implemented fault tolerant client/server we came up with a new
error class that when returned gave the user the understanding that a
condition occurred on a communicator that has rendered the communicator
useless and one should clean it up before continuing on. The point is
there was a concrete understanding of the error and what could be done
to recover. As opposed to a general class that say's everything is
borked or not which essential doesn't give you much because you'll end
up eventually having to define a more specific class of error IMO.<br>
<br>
--td<br>
<blockquote
cite="mid:OF53A2ED6B.B707548F-ON852577A6.00422ED4-852577A6.0047BF89@us.ibm.com"
type="cite"><br>
<br>
<br>
<font face="sans-serif" size="2">Dick Treumann - MPI Team
<br>
IBM Systems & Technology Group<br>
Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601<br>
Tele (845) 433-7846 Fax (845) 433-8363<br>
</font>
<br>
<br>
<tt><font size="2"><a class="moz-txt-link-abbreviated" href="mailto:mpi3-ft-bounces@lists.mpi-forum.org">mpi3-ft-bounces@lists.mpi-forum.org</a> wrote on
09/21/2010
04:54:08 PM:<br>
<br>
> [image removed] </font></tt>
<br>
<tt><font size="2">> <br>
> Re: [Mpi3-ft] Defining the state of MPI after an error</font></tt>
<br>
<tt><font size="2">> <br>
> Bronis R. de Supinski </font></tt>
<br>
<tt><font size="2">> <br>
> to:</font></tt>
<br>
<tt><font size="2">> <br>
> MPI 3.0 Fault Tolerance and Dynamic Process Control working Group
</font></tt><br>
<tt><font size="2">> <br>
> 09/21/2010 04:59 PM</font></tt>
<br>
<tt><font size="2">> <br>
> Sent by:</font></tt>
<br>
<tt><font size="2">> <br>
> <a class="moz-txt-link-abbreviated" href="mailto:mpi3-ft-bounces@lists.mpi-forum.org">mpi3-ft-bounces@lists.mpi-forum.org</a></font></tt>
<br>
<tt><font size="2">> <br>
> Please respond to "Bronis R. de Supinski", "MPI 3.0
Fault Tolerance <br>
> and Dynamic Process Control working Group" </font></tt>
<br>
<tt><font size="2">> <br>
> <br>
> Dick:<br>
> <br>
> Re:<br>
> > The current MPI standard does not say the MPI implementation
is totally <br>
> > broken once there is an error. Saying MPI state is undefined
after an <br>
> > error simply says that the detailed semantic of the MPI
standard
can no <br>
> > longer be promised. In other words, after an error you leave
behind the <br>
> > security of a portable standard semantic. You are operating
at your own <br>
> > risk. You do not need to read more than that into it.<br>
> <br>
> Perhaps my problem with this position is that I come from the<br>
> background of language definitions for compilers. When you<br>
> read "undefined" in the OpenMP specification then you are<br>
> being told that things are broken and the implementation does<br>
> need to do anything or even tell you what they actually do (and<br>
> I believe the same is true for the C and C++ standards). An<br>
> alternative is "implementation defined", which requires
the<br>
> implementer to document what they actually do. Without that,<br>
> you cannot even rely on actions with a specific implementation<br>
> (unless you believe "My tests so far have not failed so I am
OK").<br>
</font></tt>
<br>
<br>
<tt><font size="2">When a standard says behavior is "undefined"
in some situation, it cannot mean behavior is "broken". It cannot
mean the implementor is prohibited from making it still work. It cannot
mean the implementor is prohibited from making certain things work and
documenting them. Any statement like this in a standard would be
definition
of behavior and the behavior would no longer be "undefined".
</font></tt>
<br>
<br>
<tt><font size="2">The only thing a standard can logically mean by
"undefined"
is that the STANDARD no longer mandates the definition. </font></tt>
<br>
<br>
<tt><font size="2">Bronis says:</font></tt>
<br>
<br>
<tt><font size="2">> <br>
> I strongly feel "undefined" should be reserved for situations
that<br>
> mean "your program is irrevocably broken and the implementer
does<br>
> not need to worry about what happens to it after encountering
them."</font></tt>
<br>
<br>
<tt><font size="2">I would say this as:</font></tt>
<br>
<br>
<tt><font size="2">I strongly feel "undefined" should be reserved
for situations that mean "The standard no longer guarantees your
program
is not irrevocably broken. The implementer is not required by the
standard
to worry about what happens to it after encountering them. An
Implementation
is free to provide any "better" behavior that may be of value
but users cannot assume another implementation provides similar
behavior
so cannot assume standards defined portability."</font></tt>
<br>
<br>
<tt><font size="2">I do not see how the use if the word "undefined"
in a standard can be interpreted as a prohibition of any behavior an
implementation
might offer.</font></tt>
<br>
<br>
<br>
<br>
<tt><font size="2"><br>
</font></tt>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
mpi3-ft mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpi3-ft@lists.mpi-forum.org">mpi3-ft@lists.mpi-forum.org</a>
<a class="moz-txt-link-freetext" href="http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft">http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft</a>
</pre>
</blockquote>
<br>
<br>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
<title></title>
<img moz-do-not-send="false"
src="cid:part1.03070801.07010305@oracle.com" alt="Oracle"><br>
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">
<div class="moz-signature">Terry D. Dontje | Principal Software Engineer<br>
<div class="moz-signature"><font color="#666666" face="Verdana" size="2">Developer
Tools
Engineering | +1.781.442.2631<br>
</font>
<font color="#ff0000" face="Verdana" size="2">Oracle
</font><font color="#666666" face="Verdana" size="2"><b> - Performance
Technologies</b></font><br>
<font color="#666666" face="Verdana" size="2">
95 Network Drive, Burlington, MA 01803<br>
Email <a href="mailto:terry.dontje@oracle.com">terry.dontje@oracle.com</a><br>
</font><br>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>