Re: Dangers of intercepting SIGINT?

On 2007-02-07, Tarkin <Tarkin000@xxxxxxxxx> wrote:
On Feb 6, 1:06 pm, Joe Beanfish <j...@xxxxxxxxxx> wrote:
O, the lengths I'll go to avoid select()...

(except via manual SIGINT)- that's
what I want. Manual or programmatic
process shutdown via SIGINT. If some
other (kernel) process sends SIGTERM,
I want it to behave accordingly. That is,
processes (esp. kernel) expect the
behavior to be, 'die now', right??

If they want "die now" they signal SIGKILL

SIGTERM is another shutdown signal.
SIGHUP is too.

Also, I don't want the prog to ignore
further interrupts, because if I SIGINT twice,
I *do* want it to 'die now'. This was helpful
during development when I was
lear^H^H tuning read/write routines-
sometimes the prog would 'hang' during
read()'s, and just keeping dumping my
perror()'s...hitting ^C twice would kill it,
because at that point, I'm no longer
concerened about rogue file descriptors
or anything. I just want the tty back.

For 'production' or 'release', I would
consider ignoring further SIGINTS,
and perhaps looking into hooking
(is that term appropiate in *nix?)

"handling" perhaps