This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: setcontext in a signal handler
- From: Will Newton <will dot newton at linaro dot org>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Michael Kerrisk-manpages <mtk dot manpages at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 4 Mar 2014 16:33:11 +0800
- 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>
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.
The Open Group document[1] contains the following wording:
"Signal handlers should use siglongjmp() or setcontext() instead."
[1] http://pubs.opengroup.org/onlinepubs/009695399/functions/setcontext.html
--
Will Newton
Toolchain Working Group, Linaro