linux-c-programming.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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).