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

[Hubert Ritzdorf]

Jeff Squyres wrote:
> On Jun 3, 2009, at 11:47 AM, Hubert Ritzdorf wrote:
>
>> 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.
>>
>
>
> Hmm.  I'm not quite sure I understand; can you explain more?
>
> Are you saying that some applications MPI_SEND the *communicator 
> handle itself* to a peer?  If so, that's an erroneous program, no?  
> I'd have to check, but I thought that MPI defined all handles to be 
> local values only...?
Yes; it's erroneous but they will probably not see it since the integer 
communicator handle will be the
same on all processes as long as they don't use process spawning, 
creation of sub-communicators or other
process management functions. The users often create large nest derived 
types  and use overloaded functions to
exchange these types (as byte streams). A possible example is attached 
and in this case the PRIVATE attribute
in module mpi3 will not help to protect the private MPI data.
In this case, an integer handle for a MPI communicator might have 
advantages against a derived type since
the application cannot change the MPI private data contained in the 
derived type.
An incorrect handle can be detected by the MPI library.

Hubert
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bcast_derived.f90
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-fortran/attachments/20090605/f460dc36/attachment-0001.ksh>
-------------- 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/20090605/f460dc36/attachment-0001.bin>