[MPI3 Fortran] Agenda for MPI3 Fortran Working group next week
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,
>> 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...
Size: 3245 bytes
Desc: S/MIME Cryptographic Signature
More information about the mpiwg-fortran