Hi Bill and Dave, This is certainly not ideal from a tool's perspective, since there is nothing it can rely on. However, I understand the restrictions of the language in the MPI standard and we need to make this acceptable across the whole forum. I made the change in the document. The question is, though, can we add a mechanism for a tool to find out whether it is safe to call the routine from a particular context? To avoid the same problem in the description of this such a query mechanism, we could add a routine that returns whether a call is possible in the current context (independent of what it is). Would this work and be helpful? Martin On Feb 17, 2010, at 7:24 AM, William Gropp wrote:

I second Dave's note. A "signal handler" is a concept that depends on the OS; Dave's text is more appropriate for an OS-agnostic standard. Dave's text is also more in the spirit of the MPI standard, which allows implementations to make performance tradeoffs while reminding implementors what the Forum feels most users will expect.

Bill

On Feb 16, 2010, at 5:15 PM, Dave Goodell wrote:

...

(comments are relative to the draft PDF retrieved 2010-02-16 @ 4:30pm CST with md5sum "0fd54c6370574a93db13d3f5589d4b98")

I would like to propose alternative text for signal handling in the MPIT performance interface. The relevant text from the current draft (page 21, lines 3-5 and page 22, lines 24-25) is reproduced below:

-------8<------- 3| The routines in this section to start and stop performance variables must be safely 4| callable from any asynchronous execution context, such as a signal or interrupt handler, to 5| allow their use in sampling-based tools. ... 24| The routines in this section to read, write, and reset performance variables must be 25| callable from signal handlers to allow their use in sampling- based tools. -------8<-------

My proposed alternative: -------8<------- Advice to implementors. Although MPI places no requirements on the interaction with external mechanisms such as signal handlers, it is strongly recommended that the routines in this section to start and stop performance variables should be safe to call in asynchronous contexts. Examples of asynchronous contexts include signal handlers and interrupt handlers. Such safety permits the development of sampling-based tools. High quality implementations should strive to make the results of any such interactions intuitive to users, and attempt to document restrictions where deemed necessary. (End of advice to implementors.) ... Advice to implementors. Although MPI places no requirements on the interaction with external mechanisms such as signal handlers, it is strongly recommended that the routines in this section to read, write, and reset performance variables should be safe to call in asynchronous contexts. Examples of asynchronous contexts include signal handlers and interrupt handlers. Such safety permits the development of sampling-based tools. High quality implementations should strive to make the results of any such interactions intuitive to users, and attempt to document restrictions where deemed necessary. (End of advice to implementors.) -------8<-------

MPI has been careful in the past to leave signal safety and signal handling as a quality of implementation issue (see MPI-2.2 pp22:14, pp23:36, pp24:24, and pp384:45). I think that this was a wise decision and that we should carry it forward into new versions of the MPI Standard. I believe that with my proposed text implementations will almost always support signal safety, excepting situations where it is too difficult or impossible to do so.

Alternatively, the current MPIT text is incompatible with MPI-2.2 section 2.7 (and probably elsewhere). At the very least a proposal to change that (perfectly good, IMO) text is needed.

-Dave

William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign

_______________________________________________ Mpi3-tools mailing list [email protected] http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools

________________________________________________________________________ Martin Schulz, [email protected], http://people.llnl.gov/schulzm CASC @ Lawrence Livermore National Laboratory, Livermore, USA