2015 09 29

Attendees:

• Argonne - Ken
• Intel - Wesley
• ORNL - Geoffroy
• UTK - Aurelien

Move to GitHub

• Gave a general overview of GitHub and how we'll be using it.
  • More information will be coming out on the main MPI Forum mailing list soon.
  • We'll be keeping our text work in mpiwg-ft/mpi-standard.
    • The ULFM work is large so it will get it's own branching namespace: ulfm/
      • ulfm/master is the main branch with the ulfm work.
• Other comments and questions should be directed to Wesley

ULFM

• We delayed the discussion of RMA flush issues until we have Jim and Jeff on the call
• Talked about mpiwg-ft/ft-issues#1
  • Aurelien has a concern that threads could return MPI_ERR_REVOKED before any MPI operation has returned an error.
    • This could come up easily with the naive implementation where a flag is updated internally (but before the operation has actually returned).
  • We need to consider whether this is a problem and how we can word things to avoid it.

Error Handler Cleanup (mpi-forum/mpi-issues#1 & mpi-forum/mpi-issues#3)

• We still think that breaking backward compatibility related to the MPI_COMM_SELF is not really an issue.
  • We had general consensus from the forum that they're ok with moving in this direction (with the exception of Rolf).
• We'll plan to do a reading for these in December.

MPI_COMM_FREE Cleanup (mpi-forum/mpi-issues#4 & mpi-forum/mpi-issues#7)

• We created a couple of tickets related to cleaning up text around MPI_COMM_FREE in Bordeaux.
  • Generally, they remove some useless advice to implementors related to refcounting.
  • One ticket also adds text to say that it's invalid to start new MPI operations after calling MPI_COMM_FREE.
    • This could be an issue for attribute deletion callbacks and error handlers that want to use MPI operations. Should we prevent these use cases? Are they already prevented?