As the session_init call takes an errorhandler, the problem is not “is there a good option to replace MPI_COMM_SELF?” but “which of the many errorhandlers supplied to the many session_init calls should be used this time?"
If two libraries initialise two sessions (one each) and also both create and commit derived datatypes, which session’s errorhandler should be invoked when one of them runs out of resources? What if one specifies errors return and the other gives
a errorhandler function pointer? If the error is really bad and must cause a scoped abort, which session is killed?
There is a slide in the long slide deck that suggests solutions, none of which are particularly palatable. One such solution, for example, is that all operations must be scoped within a session - either directly taking a session handle as a function parameter
for its “create” function or involving at least one MPI object that has been derived from a session.
The default errorhandler is global state; so any sort of mutability is, in general, bad. Thus, another possibility is that all these non-scoped functions should be errors return all the time by definition, i.e. remove the possibility of having a custom errorhandler
as the default errorhandler. Perhaps this could be “errors return (preferred) or are fatal (if necessary) depending on the quality of the MPI implementation” or some similar weasel words.
Cheers,
Dan.
—
Dr Daniel Holmes PhD
Applications Consultant in HPC Research
d.holmes@epcc.ed.ac.uk
Phone: +44 (0) 131 651 3465
Mobile: +44 (0) 7940 524 088
Address: Room 3415, JCMB, The King’s Buildings, Edinburgh, EH9 3FD
—
The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
—