[LCP] Terminating signals to handle
Paul Gearon
gearon at ieee.org
Wed Jan 14 18:24:54 EST 2009
On Wed, Jan 14, 2009 at 5:32 PM, Christopher Howard <choward at indicium.us> wrote:
> I'm writing an ncurses app in C (my first C app, actually). The terminal
> mode is set to raw, so the app shouldn't reason the SIGINT signal (well, I
> guess not anyway...) But a friend of mine looked at the code and told me I
> should have a function that handles terminating signals, to make sure that
> the terminal is returned to a normal state if someone kills the program
> externally.
>
> Here are my questions: Which signals should I bother handling? I see in
> the signal(7) man page here that there are something like twenty signals
> that can be received. SIGHUP, SIGKILL, SIGTERM, and SIGSTOP seem relevant
> for the aforementioned purpose...
You can't actually intercept SIGKILL or SIGSTOP, as the system needs
these to always work as expected.
Most programs don't go to the effort of handling EVERY signal, but you
certainly can if you want. The signal(3) man page should help with a
description of all the signals, along with the default actions (you
don't need to do anything for signals that are ignored by default).
> Secondly: Can the signal function in signal.h be used to direct more than
> one kind of signal to the same function? (Rather than a separate function
> for each signal?)
Yes. The signal number is provided as the int parameter to the
registered function, so you can use the same function to do different
things in the handler.
Also, be sure to check out sigaction(2) for functions you should not
call while in a signal handler. I usually just set some state that I
check at regular points in the main code, and if the state is set,
then I handle the cleanup and exit. Don't do this from the signal
handler itself or you'll start seeing some strange things happening.
Paul
More information about the linuxCprogramming
mailing list