[Mpi3-ft] Questions about the the Proposed API document
Solt, David George
david.solt at hp.com
Tue Sep 1 10:36:17 CDT 2009
Admittedly, I have missed a lot of discussion during recent months, so feel free to ignore questions that have already been answered.
a) How is this different from using MPI_ERRORHANDLER_CREATE and MPI_COMM_ERRHANDLER_SET
a) Is it required that all callers return the same value for failed_process_count and failed_ranks?
b) If ranks are partitioned into two groups A and B such that all ranks in A can communicate and all ranks in B can communicate, but a rank in A cannot communicate with a rank in B, what should failed_ranks return for a rank in A? a rank in B?
c) I was told that MPI_Comm_validate uses a phased system such that the result of the call is based on the callers' states prior to the call or at the start of the call but with the understanding that the results are not guaranteed to be accurate at the return of the call. Is this accurate? If so, can you show an example of where this call would either simplify an application code or allow for a recovery case that would not be possible without it?
a) Is there a way to wait on the resulting request in such a way that you can access the failed_process_count and failed_ranks data?
a) Does this return count=0 for a rank that is already a member of the original application launched MPI_Comm_world?
The following assumes that the answer to the above question is yes: In order for this to have the data necessary, a "replacement" process must be created through MPI_Comm_restore (i.e. user's can't bring their own singletons into existence through a scheduler, etc.)
a) Is this intended only to be used by a process that was not previously a member of comm_names and the caller replaces an exited rank that was a member of comm_names?
b) Must MPI_Comm_rejoin and MPI_Comm_restore be used in matching way between existing ranks and newly created ranks? If ranks A and B call MPI_Comm_restore, which creates a new replacement rank C, will the call to MPI_Comm_restore hang until MPI_Comm_rejoin is called by C?
a) Does this create processes (I have assumed so in Q#4b above)? If so, I suggest that we learn from the problem with MPI_Comm_spawn from MPI-2 that interaction with a scheduler should be considered as we develop the API.
a) The name MPI_Comm_proc_gen seems like it should be MPI_Proc_gen. I see that all other routines are prefixed with MPI_Comm_, but I think that they all genuinely involve aspects of a communicator except for this one.
b) Ranks 0,1,2 are part of a restorable communicator C. Rank 2 dies. Rank 0 calls MPI_Comm_restore. Is rank 1 obligated to make any calls before using communicator C successfully? What will MPI_Comm_proc_gen return for rank 0? 1? 2? What will MPI_Comm_gen return for rank 0? 1? 2?
7) General question:
a) If rank x fails to communicate using point-to-point communication to rank y over communicator C, is it guaranteed that any collective call made by rank x or y on communicator C will immediately fail (even if the path between x and y is not used for the collective)? (or is it up to the implementation)
More information about the mpiwg-ft