Re: setcontext in a signal handler

["Michael Kerrisk (man-pages)" <mtk dot lists at gmail dot com>]

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.

Cheers,

Michael