Longjmp退出信号处理程序？

Question

From the question:

Is it good programming practice to use setjmp and longjmp in C?

Two of the comments left said:

"You can't throw an exception in a signal handler, but you can do a longjmp safely -- as long as you know what you are doing. – Dietrich Epp Aug 31 at 19:57 @Dietrich: +1 to your comment. This is a little-known and completely-under-appreciated fact. There are a number of problems that cannot be solved (nasty race conditions) without using longjmp out of signal handlers. Asynchronous interruption of blocking syscalls is the classic example."

I was under the impression that signal handlers were called by the kernel when it encountered an exceptional condition (eg divide by 0). Also, that they're only called if you specifically register them.

This would seem to imply (to me) that they aren't called through your normal code.

Moving on with that thought... setjmp and longjmp as I understand them are for collapsing up the stack to a previous point and state. I don't understand how you can collapse up a stack when a signal handler is called since its called from the Kernel as a one-off circumstance rather than from your own code. What's the next thing up the stack from a signal handler!?

Answer 1

The way the kernel "calls" a signal handler is by interrupting the thread, saving the signal mask and processor state in a ucontext_t structure on the stack just beyond (below, on grows-down implementations) the interrupted code's stack pointer, and restarting execution at the address of the signal handler. The kernel does not need to keep track of any "this process is in a signal handler" state; that's entirely a consequence of the new call frame that was created.

If the interrupted thread was in the middle of a system call, the kernel will back out of the kernelspace code and adjust the return address to repeat the system call (if SA_RESTART is set for the signal and the system call is a restartable one) or put EINTR in the return code (if not restartable).

It should be noted that longjmp is async-signal-unsafe. This means it invokes undefined behavior if you call it from a signal handler if the signal interrupted another async-signal-unsafe function. But as long as the interrupted code is not using library functions, or only using library functions that are marked async-signal-safe, it's legal to call longjmp from a signal handler.

Finally, my answer is based on POSIX since the question is tagged unix . If the question were just about pure C, I suspect the answer is somewhat different, but signals are rather useless without POSIX anyway...

Answer 2

longjmp does not perform normal stack unwinding . Instead, the stack pointer is simply restored from the context saved by setjmp .

Here is an illustration on how this can bite you with non-async-safe critical parts in your code. It is advisable to eg mask the offending signal during critical code.

Answer 3

In most systems a signal handler has it's own stack, separate from the main stack. That's why you could longjmp out of a handler. I think it's not a wise thing to do though.

Answer 4

值得一读： http : //man7.org/linux/man-pages/man2/sigreturn.2.html关于Linux如何处理信号处理程序调用，在这种情况下它如何管理信号处理程序退出，我读这个建议从信号处理程序执行longjmp（）（导致不调用sigreturn（））可能充其量只是“未定义”...也必须考虑setjmp（）的哪个线程（以及用户堆栈）被调用，并且随后调用了哪个线程（以及用户堆栈）longjmp（）！

Answer 5

You can't use longjmp to get out of a signal handler.

The reason for this is that setjmp only saves the resources (process registers) etc. that the calling-convention specifies that should be saved over a plain function call.

When an interrupt occurs, the function being interrupted may have a much larger state, and it will not be restored correctly by longjmp .