This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: setcontext in a signal handler
- From: Michael Kerrisk <mtk dot manpages at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- 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: Thu, 6 Mar 2014 09:12:39 +0100
- 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> <20140305175948 dot GK184 at brightrain dot aerifal dot cx>
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.