-
Notifications
You must be signed in to change notification settings - Fork 902
Update man pages to clarify MPI-4 error handlers #11015
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,53 @@ | ||
Almost all MPI routines return an error value; C routines as the return result | ||
of the function and Fortran routines in the last argument. | ||
|
||
Before the error value is returned, the current MPI error handler associated | ||
with the communication object (e.g., communicator, window, file) is called. | ||
If no communication object is associated with the MPI call, then the call is | ||
considered attached to MPI_COMM_SELF and will call the associated MPI error | ||
handler. When MPI_COMM_SELF is not initialized (i.e., before | ||
MPI_INIT / MPI_INIT_THREAD, after MPI_FINALIZE, or when using the Sessions | ||
Model exclusively) the error raises the initial error handler. The initial | ||
error handler can be changed by calling MPI_COMM_SET_ERRHANDLER on | ||
MPI_COMM_SELF when using the World model, or the mpi_initial_errhandler CLI | ||
argument to mpiexec or info key to MPI_COMM_SPAWN[_MULTIPLE]. | ||
If no other appropriate error handler has been set, then the MPI_ERRORS_RETURN | ||
error handler is called for MPI I/O functions and the MPI_ERRORS_ABORT error | ||
handler is called for all other MPI functions. | ||
|
||
In the sessions model, the error handler can be set during MPI_Session_init. | ||
|
||
Open MPI includes three predefined error handlers that can be used:: | ||
|
||
MPI_ERRORS_ARE_FATAL: Causes the program to abort all connected MPI processes. | ||
MPI_ERRORS_ABORT: An error handler that can be invoked on a communicator, | ||
window, file, or session. When called on a communicator, it | ||
acts as if MPI_ABORT was called on that communicator. If | ||
called on a window or file, acts as if MPI_ABORT was called | ||
on a communicator containing the group of processes in the | ||
corresponding window or file. If called on a session, | ||
aborts only the local process. | ||
MPI_ERRORS_RETURN: Returns an error code to the application. | ||
|
||
MPI applications can also implement their own error handlers. | ||
|
||
Custom MPI error handlers can be created by calling: | ||
:ref:`MPI_Comm_create_errhandler(3) <MPI_Comm_create_errhandler>` | ||
:ref:`MPI_File_create_errhandler(3) <MPI_File_create_errhandler>` | ||
:ref:`MPI_Session_create_errhandler(3) <MPI_Session_create_errhandler>` | ||
:ref:`MPI_Win_create_errhandler(3) <MPI_Win_create_errhandler>` | ||
|
||
Predefined and custom error handlers can be set by calling: | ||
:ref:`MPI_Comm_set_errhandler(3) <MPI_Comm_set_errhandler>` | ||
:ref:`MPI_File_set_errhandler(3) <MPI_File_set_errhandler>` | ||
:ref:`MPI_Session_set_errhandler(3) <MPI_Session_set_errhandler>` | ||
:ref:`MPI_Win_set_errhandler(3) <MPI_Win_set_errhandler>` | ||
|
||
Note that MPI does not guarantee that an MPI program can continue past | ||
an error. | ||
|
||
See the MPI man page for a full list of MPI error codes. | ||
|
||
See the Error Handling section of the MPI-|mpi_standard_version| standard for | ||
more information. | ||
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a reason not to put the "ERRORS" section title in this file, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't think of putting the ERRORS header in this file.
But, as I was going thru the individual manpage files, I noticed some pages had headings included ERRORS in all caps and some as Errors.
If I put the ERRORS heading in this file, then I think it's going to look odd when all the other headings are mixed case on a page.
I can change it if you want it changed anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The man pages were written over a long period of time, by different people. It's possible (likely!) that there are inconsistencies like this (ERRORS vs. Errors).
Let's make new text as consistent as possible (and potentially fix old inconsistencies). I.e., make the Errors subsection follow whatever the convention is for that level of subsection. Are there other titles of the same level of subsection that are inconsistent?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure what you're asking to do about the inconsistency regarding ERRORS vs Errors. If I move that into the ERRORS.rst file, then I guess I would use ERRORS there since that is a section heading. But then do I find the other section headings in every man page including the ones I have not yet touched and change all of those to uppercase?
I agree overall formatting consistency is desirable, but I also think consistency within a page is more important than overall consistency.
Should I be changing all section headings in this pull request? That feels a bit out of scope for the intent of this pull request.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I'm suggesting moving the subsection title into ERRORS.rst. I'm further suggesting make the capitalization of the subsection title in ERRORS.rst be consistent with whatever we do for other subsection titles at the same level in other man pages.
That being said, if we have more than just "ERRORS" vs. "Errors" inconsistencies in capitalization of subsection titles, we should probably make them all consistent. That would satisfy both overall formatting consistency and within-one-man-page consistency. I agree that this should probably be either a separate PR, or a standalone commit on this PR. It probably wouldn't be too hard to hack up a script or two to help automate making the pages' subsection titles be consistent (vs. editing all bazillion of our man pages manually). It might be worth looking at other popular man pages to see what their conventions are -- e.g., some GNU man pages like binutils or coreutils or something.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jsquyres I prefer to handle all the man page section headings changes, which I think can be scripted, as a separate pull request in order to keep that change from being tangled in more changes directly related to this pull request reviews. I also prefer to keep the ERRORS heading in each man page since there are some man pages with text about error handling which is different than what's described in ERRORS.rst. So I think keeping the ERRORS heading in each man page is more consistent and avoids getting anyone confused about where that heading went when ERRORS.rst is included.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Per discussion - this will happen in a separate PR after this PR is merged