Re: setcontext in a signal handler

[Michael Kerrisk <mtk dot manpages at gmail dot com>]

On Wed, Mar 5, 2014 at 6:59 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Wed, Mar 05, 2014 at 03:24:04PM +0100, Michael Kerrisk (man-pages) wrote:
>> On 03/05/2014 03:13 AM, Rich Felker wrote:
>> > On Tue, Mar 04, 2014 at 04:33:11PM +0800, Will Newton wrote:
>> >> On 4 March 2014 16:23, Andreas Schwab <schwab@suse.de> wrote:
>> >>> Will Newton <will.newton@linaro.org> writes:
>> >>>
>> >>>> It's not clear to me that there is any standard that mandates that
>> >>>> setcontext cannot be called from a signal handler or whether it is an
>> >>>> implementation detail of glibc. Does anybody know of any historical
>> >>>> reasons for this being the case?
>> >>>
>> >>> No function is async-signal-safe unless explicitly described as such.
>> >>
>> >> But is there a reason that setcontext is not safe to call from a
>> >> signal handler? It is not obvious to me that there is but I am far
>> >> from an expert in this type of analysis.
>> >
>> > My impression is that, formally, it's safe to use setcontext from a
>> > signal handler if and only if the signal handler did not interrupt a
>> > non-AS-safe function.
>>
>>
>> Exactly. This is how I wrote it up in my book:
>>
>> [[
>> .... when writing signal handlers, we have two choices:
>>
>> 1. Ensure that the code of the signal handler itself is reentrant
>>    and that it calls only async-signal-safe functions.
>> 2. Block delivery of signals while executing code in the main program
>>    that calls unsafe functions or works with global data structures
>>    also updated by the signal handler.
>>
>> The problem with the second approach is that, in a complex program, it
>> can be difficult to ensure that a signal handler will never interrupt
>> the main program while it is calling an unsafe function. For this reason,
>> the above rules are often simplified to the statement that we must not
>> call unsafe functions from within a signal handler.
>> ]]
>>
>> In other words, setcontext() can in theory be called from a signal
>> handler but only in the )(unlikely) case that we can guarantee that
>> the handler is not interrupting execution of a non-async-signal-safe
>> function in the main program.
>
> Normally a correct program using signals will keep them blocked most
> of the time and only unblock them at specific times when it can
> properly handle them and needs to (such as before performing a
> potentially-blocking, AS-safe operation). This is the idiom
> sigwaitinfo, pselect, and (the nonstandard) ppoll are built around and
> I don't think it's so unlikely except in code written by novices who
> don't understand signals.

True; that's an important exception to what I said.