[Mpi3-tools] Changes to the MPI_T*_ document

[Martin Schulz]

Hi all,

Sorry for being quiet on this topic over the last few weeks, 
I was overwhelmed with other stuff.

I started editing the MPI Tool Information Interface document
and will send out a new version for review soon.

Before that, I wanted to bring up three issues that were raised
during the last reading that require a bit more discussion:

- Naming: People didn't like MPI_T_ and wanted something
more expressive. MPI_Tool_ would be the obvious choice
and that would be fine with me. Does anyone have a better
suggestion? We can't spend more than four characters on
it, though, or we will run into problems with the max. name
size (even after shortening some names). Also, I would like
this to be the final name change :).

- Use of unsigned datatypes in the list of MPI datatypes MPI_T
can use: the argument was that counters and resource sizes
should always be 0 or more. This would make the list of
approved types (also, people requested LONG to be added)

MPI_UNSIGNED_INT
MPI_UNSIGNED_LONG
MPI_UNSIGNED_LONG_LONG
MPI_DOUBLE
MPI_CHAR
MPI_COUNT

Does this sound good? Do we need the signed version for
some/all of these as well? It would be good to keep the list
small, though, since tools will have to have long switch
statements with a case for every type.

- We had some lengthy discussion on the thread and async
signal safety. Below is a suggestion for a rewrite - once I get
some feedback from our group, I will forward this to Brian,
since he had the most issues with the current wording.

\begin{implementors}
Sampling based tools rely on the ability to call the MPI
tool information interface, in particular routines to start, stop,
read, write and reset performance variables, from any program 
context, including asynchronous contexts such as signal handlers. 
MPI implementations should strive, if possible in their particular
environment, to enable this behavior for all or a subset of the
routines mentioned above. If implementing only a subset, the
read, write, and reset routines are typically the most critical
for sampling based tools. If an MPI implementation
is not able to provide such a behavior or if the behavior is only
guaranteed under certain circumstances (e.g., for certain signals), 
this should be clearly documented, e.g., through the description 
return by {\mpifunc MPI\_T\_Get\_info}.
\end{implementors}

Please let me know if you have any comments on the issues 
above.

Thanks!

Martin




________________________________________________________________________
Martin Schulz, schulzm at llnl.gov, http://people.llnl.gov/schulzm
CASC @ Lawrence Livermore National Laboratory, Livermore, USA