[Mpi3-ft] Defining the state of MPI after an error
Bronis R. de Supinski
bronis at llnl.gov
Mon Sep 20 09:17:43 CDT 2010
Josh:
Without having reviewed your specific proposal, my
opinion is that it is a step in the right direction.
If it results in a set of error after which the
implementation expects to remain usable then it will
solve MPI's most glaring FT issue.
Bronis
On Mon, 20 Sep 2010, Joshua Hursey wrote:
> During EuroMPI and the MPI Forum meeting last week the issue of the MPI state after an error was brought up a few times. The issue is that since the state is undefined then no portable program can be written that uses the errorhandlers then MPI functionality following the error. This issue is particularly difficult for applications that wish to catch informational or warning type errors (e.g., MPI_ERR_COUNT, MPI_ERR_TAG, MPI_ERR_UNSUPPORTED_OPERATION). These operations are often recoverable by the MPI implementation and/or the application.
>
> To address this portability issue, I am bringing out the MPI_ERR_CANNOT_CONTINUE error class from the stabilization proposal. I presented the idea to the MPI Forum during a plenary session last week and received a positive response on building a formal proposal [Straw vote: 22 (yes), 0 (no), 3 (abstain)].
>
> I have created a first draft of the proposal for the working group to review on the wiki at the link below:
> https://svn.mpi-forum.org/trac/mpi-forum-web/wiki/ft/err_cannot_continue
>
> I would like to have this proposal ready by the Oct. meeting so we can have a formal plenary session on it. If all goes well, maybe we can get a first reading by Dec.
>
> Let me know what you think about this proposal.
>
> -- Josh
>
> ------------------------------------
> Joshua Hursey
> Postdoctoral Research Associate
> Oak Ridge National Laboratory
> http://BLOCKEDwww.BLOCKEDcs.indiana.edu/~jjhursey
>
>
> _______________________________________________
> mpi3-ft mailing list
> mpi3-ft at lists.mpi-forum.org
> http://BLOCKEDlists.mpi-forum.org/mailman/listinfo.cgi/mpi3-ft
>
>
More information about the mpiwg-ft
mailing list