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, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA