[Mpi3-tools] alternative signal handler text

[Martin Schulz]

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
> Mpi3-tools at lists.mpi-forum.org
> http://*lists.mpi-forum.org/mailman/listinfo.cgi/mpi3-tools
>

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