This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: setcontext in a signal handler


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.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]