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