[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week

[Iain Bason]

On Jun 4, 2009, at 11:31 AM, Jeff Squyres wrote:

> On Jun 3, 2009, at 10:37 AM, Supalov, Alexander wrote:
>
>> One of those virtues was an essential ABI compatibility by design  
>> within the Fortran interface of any particular MPI. As soon as  
>> anything but a pointer to the object internals creeps into the  
>> handle, this virtue will be gone.
>>
>
> Forgive me, but bringing ABI into this discussion is misleading at  
> best.  :-)
>
> There is no ABI between fortran implementations without specific  
> intent from the implementor.  For example, Open MPI and MPICH2 do  
> not have any Fortran ABI compatibility.  One simple/obvious reason  
> for this is that the integer constant values are different between  
> the two.  So yes, INTEGER handles are still the same size and type  
> representation, but they have entirely different values between Open  
> MPI and MPICH2 (and between MPICH1 and MPICH2!) such that you can't  
> compile a Fortran MPI application with one MPI implementation,  
> change your LD_LIBRARY_PATH, and then seamlessly run with a  
> different MPI implementation.
>
> There are other reasons why this won't work that aren't worth  
> discussing (unless someone cares); my point in this mail is that  
> making a statement implying that integers better allow ABI than  
> other data structures/types/whatever is misleading.  If MPI  
> implementation A wants to be Fortran ABI compatible with MPI  
> implementation B, they can be: A will just have to use the same  
> handle data type/structure/whatever *and values* as B (and follow  
> other conventions from B issues not discussed here).
>
> In short: All MPI's use the same INTEGER handle type today because  
> they have to, but that does *not* make them ABI compatible.

I think Alexander's point is that it is desirable for a particular  
implementation to maintain backwards binary compatibility with  
previous versions of that implementation.  If some implementation  
defined a communicator as a derived type that contained all the  
internal state the library needs, then that implementation would be  
unable to change that derived type without breaking backwards  
compatibility.

However, I think implementors are smart enough to realize that, and to  
define a communicator as a pointer to some opaque type.

Nick seems to want them to be more than a pointer to an opaque type,  
but I'm not sure exactly what he wants, nor why he wants it.

Iain