[Mpi3-bwcompat] call minutes 2010.5.28

[Fab Tillier]

Attendees: Dave Goodell, Jeff Squyres, Fab Tillier

- Failbook, Lamebook, and @BPGlobalPR good time sinks while waiting for folks to call in.
- Forum keeps going in circles on how to handle MPI_COUNT, enough so that David Solt gave up.
- Discussing this issue for quite some time (started in Portland last November as far as I know, maybe earlier.)
- No proposed solution has been satisfactory to the majority of forum members.

Summary of proposed solutions to date (please help flush this out, as I am lacking context):
1. Define MPI_COUNT only for MPI-IO functions.  Rejected: needs some changes in MPI_Get_count, etc, which have ramifications on other APIs, or introduce new MPI_Get_count_xxx.
2. Define MPI_COUNT for all functions.  Rejected: why touch functions were a need hasn't been demonstrated (you can send more than 2^31 elements by creating datatypes.)
3. Define MPI_COUNT for new functions that have some kind of suffix.  Rejected: what is the proper suffix, how do you handle exponential growth when you introduce the next suffix, blows up API surface area.

Action Items:
- Fab: Put together slides for June meeting (short on time, if everyone can send me or point me to slides related to this that were previously presented, please do.)
- Quincey, and everyone else: Make sure this is palatable to you
- Everyone: help Fab make a good presentation. :)

Plan:
Propose MPI_COUNT for all functions, define MPI_COUNT as >= int, allowing backward compatibility while also allowing moving forward.  No requirement to support either int or >int - that's an implementation choice.

Benefits:
- lets implementers respond to customer demand without breaking backward compatibility for existing codes (ABI can be kept identical if MPI_COUNT defined as int.)
- keeps API surface area manageable for implementers that don't support MPI_COUNT > int.

Disadvantages:
- doubles test surface area for implementers providing both int and > int implementations
- MPI_COUNT > int breaks F77?  Jeff says we don't care, as there aren't any F77 compilers anymore, and the F90 and newer compilers are fine with this.
- doesn't set precedent for how to handle changes like this in the future.

Questions:
- Do we allow implementations to provide both int and > int support simultaneously for Fortran using polymorphism?

Jeff, Dave, please fill in if I've missed something.
-Fab