[Mpi3-tools] reviewing the document

[Jeff Squyres]

I committed a bunch of punctuation, grammar, and minor word changes in r735.  I only got up to section 1.2.2 (more below).  I'm sorry, but the change bars have made the latex completely unreadable; I was not able to provide even more change bars.

I only got up to section 1.2.2 because Martin and I spent a long time on the phone talking about the conversion functions.  I'm still not quite sure what to do.  Here's some of the points we talked about (some of which have no resolution):

1. There's no such thing as an "MPI resource".  The spec defines "MPI handles" and "MPI objects"; we need to couch our definitions in those terms.  I submitted some suggested text to Martin for section 1.2.2, but did not have time to apply it to the rest of the document.

2. There's currently no way to free MPIT_MPI_Resource handles (see #3 before saying that you don't need this :-) ).

3. MPICH may not need real handles for MPIT_MPI_Resource instance (because they're bit-mapped integers), but pointer-driven MPI implementations like Open MPI (may) need at least 2 values: the handle and the type of the handle.  Hence, you need to be able to free MPIT_MPI_Resource handles.

4. I'm really re-thinking the whole idea that the functions in 1.2.2 provide compile-time type safety.  Specifically: I don't think that they do.  Sure, you're protected from this kind of bozo error:

  MPIT_MPI_Resource_communicator(MPI_INT, ...);

but you're not protected from this kind of IMNSHO-more-insidious error:

  MPIT_MPI_Resource_communicator(MPI_COMM_WORLD, &foo);
  MPIT_Perfvar_handle_allocate(x, y, foo, &handle);

where (x, y) refers to a performance variable associated with MPI datatypes.

Sure, you'll get a run-time error, but what did we really gain with the conversion function there?  The conversion function is acting like a cast -- nothing more.  And just like a real casting operator, it (effectively) tells the compiler "don't worry, I know what I'm doing -- don't complain about types here."  I.e., we give up the compile time type safety.  You can still hose yourself w.r.t. the foo MPIT handle and get no protection from the compiler.

So why have it?

I'm wondering if there are really two options here:

1. Have a real casting operating (somewhat akin to Martin's initial proposal): have a casting function that returns the OUT value (vs. an int error code).  Then you can nest the output of the casting function as an argument to MPI_Perfvar_handle_allocate(), for example.

2. Have 9 different versions of MPI_Perfvar_handle_allocate() and MPI_Controlvar_handle_allocate() -- one for each MPI handle type.

I assume most people will recoil from #2.  But... hmm.  It *is* the safest way to go.  But ugly (because it's lots of functions).  Hmm...

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