RE: Signal handler and longjmp question

Yi Wang <[email protected]>
Newsgroups org.kernel.vger.linux-c-programming
Message-ID <[email protected]>
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: [email protected]
> To: [email protected]
> Subject: Re: Signal handler and longjmp question
> CC: [email protected]
>
> 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 [email protected]
> 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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.