Hi Howard, 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 [email protected]<mailto:[email protected]> 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. — On 21 Aug 2018, at 14:59, Pritchard Jr., Howard <[email protected]<mailto:[email protected]>> wrote: Hi Aurelien, responses interleaved below: -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory From: mpiwg-sessions <[email protected]<mailto:[email protected]>> on behalf of Aurelien Bouteiller <[email protected]<mailto:[email protected]>> Reply-To: MPI Sessions working group <[email protected]<mailto:[email protected]>> Date: Tuesday, August 21, 2018 at 7:41 AM To: MPI Sessions working group <[email protected]<mailto:[email protected]>> Subject: Re: [mpiwg-sessions] question about section 8.3 and MPI_COMM_SELF Howard, A similar issue has been discussed during the last virtual meeting about what happens to errors in MPI_INIT (in which it is not guaranteed that MPI_COMM_SELF) is completely initialized yet, and error handlers had no chance to be set by users yet). One of the feedback of the call is that in such cases, returning an error code is a desired outcome. That would particularly apply to session_init. I like this idea! I’ll put some text into 8.3 stating this behavior when using the Peer to Peer model for initialization. For the rest of the session operations, it could be beneficial to be able to set explicitly (i.e. with a session api call) what is the default/fallback error handler for when the MPI_COMM_SELF object has not been created, and the rules for precedence between these mechanisms when both are in play. I do not remember the group discussing these issues in much more details. Agreed. We need to come up with some way to deal with the way MPI_COMM_SELF is used currently as a grab bag of things. Best, Aurelien On Aug 20, 2018, at 14:20, Pritchard Jr., Howard <[email protected]<mailto:[email protected]>> wrote: Hi Folks, Does anyone in the WG recall what our thoughts were concerning the case when MPI encounters an error in an MPI function not associated with a particular communicator, file, window, or (now) session? I’m concerned about this sentence in 8.3: When using the MPI calls that are not related to any objects are considered to be attached to the communicator MPI_COMM_SELF. Looking at the old power point slide deck, this problem is mentioned, but not addressed. Howard -- Howard Pritchard B Schedule HPC-ENV Office 9, 2nd floor Research Park TA-03, Building 4200, Room 203 Los Alamos National Laboratory _______________________________________________ mpiwg-sessions mailing list [email protected]<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions _______________________________________________ mpiwg-sessions mailing list [email protected]<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpiwg-sessions The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.