[mpich-devel] Sessions Considering Changing MPI_COMM_WORLD

[Jeff Hammond]

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 <wesley.bland at intel.com>
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
jeff.science at gmail.com
http://jeffhammond.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20171030/d591ff06/attachment.html>