[Mpi3-tools] alternative signal handler text

[Marty Itzkowitz]

On 2/21/10 12:55 AM, Martin Schulz wrote:
> 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?

Not really.  It's no different from returning an error code in that context.

Aren't most implementations of MPI Unix or Unix-like?  Why can't this fact
be used in writing a definition?

    Marty

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