[Mpi3-tools] Issues with Fortran bindings for MPI_Pcontrol

[Mohror, Kathryn]

Hello all,

Just as a heads up, we will be discussing issues with the new Fortran bindings and the profiling interface during this week's tools wg call (Thursday 8:00 AM PDT). Craig Rasmussen and Rolf Rabenseifner have graciously agreed to join the call to explain to us what the specific problems are and what might be done to address them. It would be great if others want to join and help out with the discussion.

I'll send out a reminder later in the week.

Kathryn

On Apr 15, 2013, at 1:03 PM, Jeff Squyres (jsquyres) <jsquyres at cisco.com<mailto:jsquyres at cisco.com>> wrote:

On Apr 14, 2013, at 9:01 PM, Jeff Hammond <jhammond at alcf.anl.gov<mailto:jhammond at alcf.anl.gov>> wrote:

It seems better to correct the text than to break the existing
definition of MPI_PCONTROL.  What error code would be returned
anyways?


I think the point is that we don't know what could/would be returned by Pcontrol, because Pcontrol can be subsumed by a profiling library, and therefore it can do whatever it wants.

The issue here is that the C API is varargs, and therefore allows you to pass in whatever you want to Pcontrol (at least in C), and therefore a tool (or the underlying C MPI API) can document what arguments it expects.

There's (at least) two problems with this:

1. If a profiling library and the MPI library have differing arguments that they expect, even though varargs makes the different signatures compile-time safe, there could still be run-time errors (this is a contradiction that I've never understood in the definition of Pcontrol).

2. Fortran has no varargs.  Prior to MPI 2.2, we actually did have a "..." in the Fortran prototype to indicate that you could do whatever you wanted for this signature.  And that was fine in the days before strict dummy argument type checking.  But now we mandate struct signature checking, and ... had to go, because it's not legal Fortran.  And now the text doesn't say "Fortran implementations can add whatever parameters they want" (which has problems, anyway).

I'm really in favor of ditching the PMPI layer and putting something better there.

--
Jeff Squyres
jsquyres at cisco.com<mailto:jsquyres at cisco.com>
For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/


_______________________________________________
Mpi3-tools mailing list
Mpi3-tools at lists.mpi-forum.org
http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

______________________________________________________________
Kathryn Mohror, kathryn at llnl.gov<mailto:kathryn at llnl.gov>, http://people.llnl.gov/mohror1
CASC @ Lawrence Livermore National Laboratory, Livermore, CA, USA




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20130415/48ee4a07/attachment-0001.html>