[Mpi3-tools] alternative signal handler text

[William Gropp]

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