[mpich-devel] Sessions Considering Changing MPI_COMM_WORLD
Bland, Wesley
wesley.bland at intel.com
Mon Oct 30 13:33:47 CDT 2017
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20171030/6251fdf2/attachment.html>
More information about the devel
mailing list