I think I understand you're saying: - it's ok to abort during MPI_INIT (we can rationalize it as the default error handler) - we should only abort during MPI functions
Is that right? If so, I agree with your interpretation. :-) ...with one addition: it's ok to abort before MPI_INIT, because the MPI spec makes no guarantees about what happens before MPI_INIT. Specifically, I'd argue that if you "mpirun -np N a.out" and at least 1 process calls MPI_INIT, then it is reasonable for OMPI to expect there to be N MPI_INIT's. If any process exits without calling MPI_INIT -- regardless of that process' exit status -- it should be treated as an error. Don't forget that we have a barrier in MPI_INIT (in most cases), so aborting when ORTE detects that a) at least one process has called MPI_INIT, and b) at least one process has exited without calling MPI_INIT, is acceptable to me. It's also acceptable to the first point above, because all the other processes are either stuck in the MPI_INIT (either at the barrier or getting there) or haven't yet entered MPI_INIT -- and the MPI spec makes no guarantees about what happens before MPI_INIT. Does that make sense? On Dec 16, 2009, at 10:06 AM, George Bosilca wrote: > There are two citation from the MPI standard that I would like to highlight. > > > All MPI programs must contain exactly one call to an MPI initialization > > routine: MPI_INIT or MPI_INIT_THREAD. > > > One goal of MPI is to achieve source code portability. By this we mean that > > a program written using MPI and complying with the relevant language > > standards is portable as written, and must not require any source code > > changes when moved from one system to another. This explicitly does not say > > anything about how an MPI program is started or launched from the command > > line, nor what the user must do to set up the environment in which an MPI > > program will run. However, an implementation may require some setup to be > > performed before other MPI routines may be called. To provide for this, MPI > > includes an initialization routine MPI_INIT. > > While these two statement do not necessarily clarify the original question, > they highlight an acceptable solution. Before exiting the MPI_Init function > (which we don't have to assume as being collective), any "MPI-like" process > can be killed without problems (we can even claim that we call the default > error handler). For those that successfully exited the MPI_Init, I guess the > next MPI call will have to trigger the error handler and these processes > should be allowed to gracefully exit. > > So, while it is clear that the best approach is to allow even bad application > to terminate, it is better if we follow what MPI describe as a "high quality > implementation". > > george. > > > On Dec 15, 2009, at 23:17 , Ralph Castain wrote: > > > Understandable - and we can count on your patch in the near future, then? > > :-) > > > > On Dec 15, 2009, at 9:12 PM, Paul H. Hargrove wrote: > > > >> My 0.02USD says that for pragmatic reasons one should attempt to terminate > >> the job in this case, regardless of ones opinion of this unusual > >> application behavior. > >> > >> -Paul > >> > >> Ralph Castain wrote: > >>> Hi folks > >>> > >>> In case you didn't follow this on the user list, we had a question come > >>> up about proper OMPI behavior. Basically, the user has an application > >>> where one process decides it should cleanly terminate prior to calling > >>> MPI_Init, but all the others go ahead and enter MPI_Init. The application > >>> hangs since we don't detect the one proc's exit as an abnormal > >>> termination (no segfault, and it didn't call MPI_Init so it isn't > >>> required to call MPI_Finalize prior to termination). > >>> > >>> I can probably come up with a way to detect this scenario and abort it. > >>> But before I spend the effort chasing this down, my question to you MPI > >>> folks is: > >>> > >>> What -should- OMPI do in this situation? We have never previously > >>> detected such behavior - was this an oversight, or is this simply a "bad" > >>> application? > >>> > >>> Thanks > >>> Ralph > >>> > >>> > >>> _______________________________________________ > >>> devel mailing list > >>> de...@open-mpi.org > >>> http://www.open-mpi.org/mailman/listinfo.cgi/devel > >>> > >> > >> > >> -- > >> Paul H. Hargrove phhargr...@lbl.gov > >> Future Technologies Group Tel: +1-510-495-2352 > >> HPC Research Department Fax: +1-510-486-6900 > >> Lawrence Berkeley National Laboratory > >> _______________________________________________ > >> devel mailing list > >> de...@open-mpi.org > >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > > > > _______________________________________________ > > devel mailing list > > de...@open-mpi.org > > http://www.open-mpi.org/mailman/listinfo.cgi/devel > > > _______________________________________________ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel > -- Jeff Squyres jsquy...@cisco.com
