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

[N.M. Maclaren]

On Jun 3 2009, Supalov, Alexander wrote:

> Thanks. On the C side, the opaque objects are usually pointers to structs 
> (OpenMPI, HP-MPI - please correct me if I'm wrong) or predominantly int 
> handles (MPICH2 and friends, with notable exceptions like MPI_Request 
> and, gee, MPI_File that are again pointers - thanks to ROMIO).

That's my observation, and not just on those MPIs.

>One way to resolve these issues is to specify that the 
>TYPE(MPI_Communicator) "is an interoperable type", or "does not have 
>pointer and allocatable components", or "does not have allocatable 
>components", etc. One has to decide what to do here. Again, using what 
>we did for TEAMs in coarrays might be useful (but here following the C 
>binding closely might be a better guiding principle).

That is a truly horrible hack!  The whole point about the semantics of
communicators is that they DO behave as if they have such components.
However, I am afraid that the best solution may end up being a horrible
hack, so I am not saying that your idea shouldn't be considered.

>Yes, I agree, which is why guidance is needed beyond just slapping 
>an "opaque" label. If Fortran had "handles" or at least "value types" 
>in the language, we would use that. C has some sort of "incomplete 
>type" concept which is what I would have used but there may be reasons 
>against it...

Eh?  C has at least three such concepts, all of which are grossly unsuitable
for MPI opaque types in different ways: incomplete arrays, anonymous structs
and whatever-it-is that 'void *' points to.  I may have missed another, so
please tell me if so.

And again, the fact that they are all grossly unsuitable doesn't mean that
one of them isn't the best solution (of a VERY unattractive choice).

>Again, how is this handled with C. Why not follow the lead? Even if it 
>is a crappy lead :-)

Because the fundamental concepts of Fortran and C are so different.  There
is no reason to believe that a hack that will work for one will work for the
other.  Yes, I agree that the lead should be looked at, and checked for
plausibility.


Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email:  nmm1 at cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679