[Mpi3-tools] reviewing the document

[Dave Goodell]

On Jan 25, 2011, at 5:35 PM CST, Jeff Squyres wrote:

> 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.

Agreed.

> 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.

Technically, even if you have an Open MPI-esque implementation, you could implement your MPI object structs s.t. they have a common header containing RTTI and then gently cheat on C's strict-aliasing rules.  This would avoid the allocation issues.  However, I'm guessing that things aren't already implemented this way for you and such a change could be fairly intrusive.

> 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 agree, I don't really see the justification for the N routines, as I indicated on the concalls.

> 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...

#1 is cute, but it doesn't match MPI error handling conventions, and I'd rather not begin passing the error code back as an OUT arg for just this small set of conversion routines.

#2 is horrifying, we will be laughed at for years to come if we attempt something like this.

My vote is still for one of the following:

3. No conversion routines, just a (void*) arg and assume that the implementation will provide any reasonable amount of runtime type checking that it can.  This would work fine for MPICH2 at least, but I think that the resource args to the *var_handle_allocate routines isn't very self-explanatory in this case.

4. A single conversion routine that takes a (void*) and a constant indicating the type of the input pointer.  Like this:

  int MPIT_Convert_object(void *object_ptr, int obj_type, MPIT_MPI_Resource *resource);

(rename resource appropriately once you decide what you want to call it)  This at least makes it somewhat clear to new users what the handle_allocate routines are expecting.

-Dave