This is going to cause horrible problems. I hate to say it, but the time for MPI to have avoided hidden state was in the 1990s. Lots of MPI libraries create their own communicator from the compile-time constant rather than a communicator argument. Breaking even a few of these will ruin MPI’s exhalted reputation in the HPC world. The better option is to provide new headers and libraries for sessions that break backwards compatibility. Or just have users opt-in to sessions by not using MPI_COMM_WORLD at all. That way you’re only breaking code that wants this feature rather than many that don’t. What’s your Fortran story? If you don’t have a trivial solution for users of mpif.h, you’ve lost approximately half if MPI’s users. Jeff On Mon, Oct 30, 2017 at 11:33 AM Bland, Wesley <[email protected]> wrote:
The sessions working group is working on a proposal that, among other things, would change the way MPI_COMM_WORLD works. As much as I don't want to take things out of context for those who aren't familiar with the proposal, I'm not going to summarize the whole thing here. If you need that, look here: https://github.com/mpiwg-sessions/sessions-issues/wiki/sessions_cheat_sheet
On today's call, we were trying to decide the result of a backward compatibility break for the MPI_COMM_WORLD symbol. We want to keep the MPI_COMM_WORLD symbol to allow legacy codes to work, but we don't want to make it a compiler symbol anymore. It would only exist if you call MPI_INIT. To that end, MPI_INIT would look something like this:
MPI_Init(...) { MPI_Comm *comm; MPI_Session *session;
MPI_Session_init(..., session); MPI_Group_create_from_session_name(&session, "mpi://WOLRD", comm); MPI_COMM_WORLD = *comm; }
The problem here is that MPI_COMM_WORLD is no longer the compile-time constant that it was before. For example, if you're using MPI_COMM_WORLD in a library, this would cause problems.
The working group is trying to figure out the results of this to decide whether this would cause horrible problems. It seems that as long as applications are reasonably well behaved and check if the library is initialized first, they should work correctly.
What is this community's opinion of this?
Thanks, Wesley _______________________________________________ To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/devel
-- Jeff Hammond [email protected] http://jeffhammond.github.io/