signal handler problems

Applications Programming
1

Hey guys,

I am trying to write a little shell, and was writing a signal handler to handle SIGINT (I am using 'stty intr ^C' and using ctrl-C to give SIGINT).

I wrote this signal handler:

void handle_sigint()
{
        write(2,"handling sigint\n",16);
        write(1,"\nshell% ",8);
}

and here is how I am assigning it:

signal(SIGINT,handle_sigint);

I do this right at the beginning of the code.

Now if I give it SIGINT, the function gets called and I get the correct output on screen - but only once. The second time that I give it ctrl-C, the shell exits.

Should I be doing anything else in the handler to allow for subsequent trapping of SIGINT?

I am working on HP-UX 11.11 PA-RISC.

2

You should not use signal() for new code. But if you do, you must repeat the call to signal as the first line in the signal handler. The signal goes back to the default action each time with signal(). This is dumb and that is why no one uses signal() anymore.

Ideally, use sigaction() instead. Then whether or not the signal get reset each time is controlled with a flag and you do not want to set that flag.

3

Thanks Perderabo.. Actually went through the man page for sigaction, but it seemed like such a lot of work... and I was being a bit lazy. But guess I dont really have a choice. Well, back to the code!

4

Establishing the signal handler
----------------------------------
signal (SIGALRM, catch_alarm);

Calling the signal handler
-------------------------
catch_alarm (int sig)
{
keep_going = 0;
signal (sig, catch_alarm);
}

The above codes are just the signal handling snippet from the larger program.

Please explain how the call of the signal handling functions here. how the signal inside catch_alarm gets called when no argument is passed while establishing the handler.

5

Adding to Perderabo's comment on using newer semantics of signal handling instead of older semantics.

Using signal function, while executing the code block within the signal handler there is no guarantee that another signal of the same type delivered would be handled the same way; instead the second signal of the same type delivered would default to its default action which in most of the cases would be to terminate.

for example:

signal code block {
/*  code instruction is currently here */  <== this instruction point
}

when its at the " this instruction point " and if a signal is again delivered at this point, proper house keeping operations intended for the signal handler will not be completed.

But this never happens with the newer semantics with sigaction,
when the code instructions are executed within the signal action block kernel guarantees that it will not deliver the same signal type until the signal action block is completed.

so with the newer semantics you are guaranteed that your house keeping operations are done.