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

Hubert Ritzdorf ritzdorf at it.neclab.eu
Wed Jun 3 10:47:52 CDT 2009

Jeff Squyres wrote:
> On Jun 3, 2009, at 7:35 AM, Supalov, Alexander wrote:
>> 2. Review of new MPI derived types to be used, for example,
>> type(MPI_Comm).
>> AS> There's certain beauty in the integer handle approach of the 
>> current Fortran interface. It specifies pretty clearly that the meat 
>> of the object lives outside of the application. With the derived 
>> type, implementors might be tempted to put more than a handle into 
>> the application space, and then we may have issues with tools, 
>> compatibility between different MPI versions, etc.
> Before the Fortran guys storm in with their replies ;-), I'll mention 
> that I think that using integer handles is a horrid idea for Fortran.  
> It was done with good reason back in the 90s, but the language has 
> evolved such that we can give much better type safety these days.  
> I've seen too many customers accidentally use the wrong handle type 
> for a parameter and didn't know it because the compiler didn't 
> (couldn't) tell them.  C and C++ give this protection -- Fortran can 
> too, now, so we should allow, nay, *encourage*, that.
> I don't see the problem of allowing an MPI implementation to put more 
> information in a language handle (this is already allowed in the C++ 
> bindings).  Can you explain more specifically what you mean?
An advantage of integer handles could be that the application programs 
are not able to send MPI communicator descriptions (derived types)
as byte stream to other MPI processes and to overwrite the corresponding 
(MPI private) info in the destination process.
I have seen application programs which are sending derived user types 
including Fortran pointer descriptions as byte streams
to other MPI processes and which are using data (ASSOCIATED) from these 
Fortran pointer descriptions.
If such program put/have communicators in such derived user types, the 
MPI library might use incorrect communicator
data and cannot check this.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20090603/d286e31b/attachment-0001.bin>

More information about the mpiwg-fortran mailing list