[Mpi3-tools] MPI handles debugging interface

[David Lecomber]

Hi John and all,

FWIW, all tools folks will do is just dlsym() lookups for the function,
casting them to what we expect them to be, and calling them.  So, only
so long as the tool implementor has the same version of the header file
as the library had, do we have type safety - hence extensions to
existing functions and structs must be ruled out, extensions can only
come via new functions and new structs.

Can we be sure, in defining something strictly, that we've thought of
everything?  Ashley mentioned an extra byte count field, which is just
one example we missed last year in defining an interface.  The OMPI guys
have a few extra fields at the end of a struct in the old MPI debug
interface -- knowing that no-one else is using those.  

I guess what I had in mind was more a "Properties" style approach, you
ask the debug interface what properties are supported, it gives you a
list back, and you call a single function to get their (single) values -
eg. communicator_get_attribute(foo).  That'd give a debugger the ability
to say "this communicator has attribute 'foo', I haven't a clue what it
means, but I'm telling you it has value 'bar'" -- for any MPI added
extension from day one.

Overkill probably, but I just wanted to check opinions.

Regards
David


On Wed, 2009-06-03 at 09:40 -0400, John DelSignore wrote:
> IMHO, type safety is extremely important and any solution that is not type safe is a non-starter.
> 
> Cheers, John D.
> 
> 
> Jeff Squyres wrote:
> > In chatting with David Lecomber while we're working on revising the MPI3
> > handle debugging interface per the recent discussions in this group
> > (moving away from the One Big Struct approach), David asked a me a
> > question that I thought might be appropriate for the larger group.
> > 
> > Why use a bunch of individual query functions when we could have a
> > single, much more general form that is more easily extensible?  The
> > query function would essentially be driven by an enum indicating the
> > specific request, and the OUT arguments could be varargs.  Perhaps
> > something like this:
> > 
> > =====
> > int mpidbg_comm_query_element(mpidbg_comm_handle_t handle,
> >                               enum mpidbg_comm_query_element_t element,
> >                               ...);
> > =====
> > 
> > Here's a sample use case:
> > 
> > =====
> > /* initial query to allow the DLL to bundle up *all* the data into a
> > handle */
> > mpidbg_comm_query(image, image_info, ..., mpi_communicator, &handle);
> > 
> > /* Query the "basic" communicator info from the handle */
> > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_BASIC, &flags,
> > &rank, &size, ...etc.);
> > 
> > /* Query the communicator process info from the handle */
> > mpidbg_comm_query_element(handle, MPIDBG_COMM_QUERY_PROCS,
> > &num_local_procs, &local_procs,
> >                           &num_remote_procs, &remote_procs);
> > =====
> > 
> > +++ Advantage: this one function can be extended simply by adding new
> > enum values, possibly in an MPI implementation-specific way (e.g., have
> > some non-standard / value-add functions)
> > 
> > --- Disadvantage: lose compiler type safety checking when
> > building/debugging tools that use this interface.
> > 
> > I don't have strong feelings either way.  I think I'm marginally in
> > favor of individual functions just because it gives type safety for
> > tools authors.  But I could be convinced to go the enum/varargs route if
> > people feel strongly.
> > 
> > Comments?
> > 
> > --Jeff Squyres
> > Cisco Systems
> > 
> > _______________________________________________
> > Mpi3-tools mailing list
> > Mpi3-tools at lists.mpi-forum.org
> > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
> > 
> > 
> _______________________________________________
> Mpi3-tools mailing list
> Mpi3-tools at lists.mpi-forum.org
> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mpi-forum.org/pipermail/mpiwg-tools/attachments/20090603/624f3084/attachment-0001.pgp>