From: Yi Wang <yi.w@live.com>
To: Steve Graegert <graegerts@gmail.com>
Cc: linux-c-programming@vger.kernel.org
Subject: RE: Signal handler and longjmp question
Date: Mon, 10 Dec 2007 14:03:20 +0800 [thread overview]
Message-ID: <BLU125-W4262DA65CFB67D8F920230EA6B0@phx.gbl> (raw)
In-Reply-To: <6a00c8d50712090606k6882a52bv2735ee3d746ba7a8@mail.gmail.com>
Well, I understand you.
Maybe I'm not expressing myself clearly.
The following drawing indicates how the kernel issues a signal. (ref:understanding linux kernel, 3rd, O'Reilly, Fig. 11-2)
Note that the function calls on the right column are kernel codes.
The kernel manages the frame setup and other stuff the signal_handler()
I'm wondering if longjmp is called in signal_handler, the the handler won't return and the system_call(),sys_sigreturn()and restore_sigcontext() will never have chance to execute.
This will break kernel's routine of handling a signal.
And I think that's bad...
Program running -----> do_signal()
received signal handle_signal()
setup_frame()
/
/
/
signal_handler() <------/
|
return
\
\
\----> system_call()
sys_sigreturn()
restore_sigcontext()
/
/
continue program <- ----/
> Date: Sun, 9 Dec 2007 15:06:22 +0100
> From: graegerts@gmail.com
> To: yi.w@live.com
> Subject: Re: Signal handler and longjmp question
> CC: linux-c-programming@vger.kernel.org
>
> On Dec 9, 2007 2:12 PM, Yi Wang wrote:
>>
>> Hi, all
>> I read from some book that a signal handler can either return or call exit, abort or longjmp, it is permitted by ANSI C.
>> However, I remember that lonjmp never returns, which in turn causes the signal handler can not return. In that case, the kernel will think the program is in signal handler forever, am I right?
>> IMHO, I think that is too bad...
>
> This is not the case. Rather than returning to the interrupted
> statement, longjmp causes control to be sent back to the setjmp() in
> the main program. Since POSIX.1 does not specify whether setjmp and
> longjmp save or restore the current set of blocked signals the use of
> sigsetjmp/siglongjmp is recommended if signals must be handled.
>
> longjmp does not return because setjmp first saves the environment to
> which longjmp can return from another point in the program. After
> returning to setjmp the process does not know that it "has been
> returned" from somewhere else. So, technically longjmp cannot not
> return.
>
> A problem with the use of setjmp/longjmp is that the environment will
> not be cleaned up (closing FDs, flushing buffers, freeing
> heap-allocated memory, and the like).
>
> \Steve
>
> --
>
> Steve Grägert
> DigitalEther.de
> -
> To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
_________________________________________________________________
Discover the new Windows Vista
http://search.msn.com/results.aspx?q=windows+vista&mkt=en-US&form=QBRE-
To unsubscribe from this list: send the line "unsubscribe linux-c-programming" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2007-12-10 6:03 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <S1751093AbXLIMzQ/20071209125516Z+241@vger.kernel.org>
2007-12-09 13:12 ` Signal handler and longjmp question Yi Wang
2007-12-09 14:06 ` Steve Graegert
2007-12-10 6:03 ` Yi Wang [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BLU125-W4262DA65CFB67D8F920230EA6B0@phx.gbl \
--to=yi.w@live.com \
--cc=graegerts@gmail.com \
--cc=linux-c-programming@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).