Re: Dangers of intercepting SIGINT?



Hello,

In the process of writing a (POSIX) threaded program, I found I
wanted a clean way to exit the program, without screwing around with a
UI (yet!). I used signal(SIGINT,my_handler) to intercept SIGINT.
my_handler pthread_join()'s my threads, sends them a boolean condition
which makes them pthread_exit(), and the calls exit(0). AFAIK,
everything is cleaned up nice and tidy.

So, my question is: does the normal action(signal handler) for ^C
(SIGINT) do anything other than halt the process in it's tracks? i.e.
is there something from the default handler I should include in my
handler? Or am I already doing much more than the default ever does?

That's not the way you're supposed to deal with signal in multi-
threaded application. You might be lucky for now on your platform, but
there is no guarantee that this luck will hold forever.

Remember: to be on the safe side, you should only call async-signal-
safe function in signal handler. See:
http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html#tag_02_04_03

Of course, this is too limitating for real world multi-threaded
programs. That why you should use the standard signal handling
framework found in the Examples section at:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_sigmask.html

Cheers,
Loic.

.



Relevant Pages

  • Dangers of intercepting SIGINT?
    ... In the process of writing a threaded program, ... wanted a clean way to exit the program, without screwing around with a ... I used signalto intercept SIGINT. ... is there something from the default handler I should include in my ...
    (comp.os.linux.development.apps)
  • Re: Dangers of intercepting SIGINT?
    ... In the process of writing a threaded program, ... wanted a clean way to exit the program, without screwing around with a ... I used signalto intercept SIGINT. ... is there something from the default handler I should include in my ...
    (comp.os.linux.development.apps)