This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: setcontext in a signal handler
- From: Rich Felker <dalias at aerifal dot cx>
- To: mtk dot manpages at gmail dot com
- Cc: Will Newton <will dot newton at linaro dot org>, Andreas Schwab <schwab at suse dot de>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Wed, 5 Mar 2014 12:59:48 -0500
- Subject: Re: setcontext in a signal handler
- Authentication-results: sourceware.org; auth=none
- References: <CANu=DmjHdiCf-jEMS6vAb9MgwG-XzYGOfMBHJr7LDvTgNRTnDg at mail dot gmail dot com> <mvmwqgaz81q dot fsf at hawking dot suse dot de> <CANu=DmiFUrEWcs83TJiW=yPcBFs814UjaMcW6AC9xNmvXwA7_w at mail dot gmail dot com> <20140305021324 dot GJ184 at brightrain dot aerifal dot cx> <53173384 dot 6040309 at gmail dot com>
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