Re: Dangers of intercepting SIGINT?

On Feb 2, 3:21 pm, "Tarkin" <Tarkin...@xxxxxxxxx> wrote:
On Feb 2, 12:31 pm, "Loic Domaigne" <loic-...@xxxxxxx> wrote:



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 interceptSIGINT.
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...

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_sigma...

Cheers,
Loic.

O.k., let me rephrase the question: could folks suggest a
strategy to intercept ^C, so that I can cleanly shut down my
server process?

Here is a rough outline of what the server does:

1) Creates five threads, each of which has two
main conditions: ACTIVE and QUIT. If the thread
is ACTIVE, it already has an open socket and is
busy communicating. If the thread's QUIT condition
changes from 0, it must close it's socket and exit.

2) Goes through the socket/bind/listen/accept
phases of establishing a server communication
routine.

3) Passes accept'ed sockets to the next
non-ACTIVE thread, and goes back to
accept'ing.

The server process (main) prints various
and sundry messages to stdout. stdin is
left open, as it is desirable in development
to shutdown the code withoutusing
"kill -s 9 server_PID", and the easiest way
I know of to do that is to hit ^C.

I wanted to avoid writing terminal-dependant
code, or messing about with terminal libraries,
etc. if at all possible, so I looked into signal
handling. I made (the probably erroneous)
that *nix derivatives associate ^C from
stdin withSIGINT.

Comments, suggestions, URL's, criticism,
etc. welcomed.

TIA,
Tarkin


My very bad. Searching previous posts on SIGINT
in (this) groups archives has turned up plenty.

Thanks,
Tarkin

.

Relevant Pages

  • Re: Dangers of intercepting SIGINT?
    ... I used signal(SIGINT,my_handler) to intercept SIGINT. ... it must close it's socket and exit. ... The server process prints various ... in a signal are very limited, you should make things in signal handler ...
    (comp.os.linux.development.apps)
  • Receiving neighbor advertisement to extract link-layer (MAC) address
    ... This is the second part of a two-part post on IPv6 socket ... struct in6_addr ipi6_addr; ... void *tmp; ... exit; ...
    (comp.os.linux.networking)
  • [9fans] APE and listen(2B)
    ... seems to somehow exit the actual listenproc, ... socket accept: Invalid argument ... int main { ... perror; ...
    (comp.os.plan9)
  • Re: error handling
    ... >> Lisa Pearlson wrote: ... >>> Imagine I have a socket read function.. ... >>> exit 1 ... > exceptions to return data yet allow additional info.. ...
    (comp.lang.tcl)
  • Re: closesocket
    ... the Wait is called in the application exit code. ... > thread since my app uses blocking socket. ... > calls closesocket and WSACleanup without waiting for the thread to ...
    (microsoft.public.windowsce.embedded.vc)