CODEWITHSUNDEEP
cunixsignals
lecardo
lecardo

Reputation: 1212

Unix - Control C and Control Z signal pick up issues

I'm experimenting around with the signals offered in Unix. The two I'm focusing on at the moment is Ctrl+C and Ctrl+Z. I want to catch the signal, and display a message to the screen. I got most of it working. Like the message displays when either signal is pressed. However it seems to only work once. I want the message to display each time Ctrl+C or Ctrl+Z are pressed. Like a loop.

#include <stdio.h>
#include <signal.h>

void handler (int signal);

int main ()
{
  if (signal(SIGINT, handler) == SIG_ERR)
  {
    write (2, "Error catching signal C \n",26);
  } 
  if (signal(SIGTSTP, handler) == SIG_ERR)
  {
    write(2, "Error catching signal Z \n", 26);
  }
  pause();
}

void handler (int signal)
{
  if (signal == SIGINT)
  {
    write(1, "CONTROLC \n", 11);
  }
  else if (signal == SIGTSTP)
  {
    write(1, "CONTROLZ \n", 11);
  }
  else
  {
    write(2, "error \n", 8);
  }
  main();
}

I attempted to use the main function so that it would restart the program again, but I'm assuming its calling main from within a signal so it behaves differently?

Upvotes: 1

Views: 567

Answers (3)

John Bollinger
John Bollinger

Reputation: 180351

Do not use signal(2), except possibly to set a given signal's disposition to SIG_DFL or SIG_IGN. Its behavior varies among different Unixes.

For portability (among POSIX systems) and better control, you should install user signal handlers via the sigaction(2) syscall. Among other things, that allows you to choose between one-shot and persistent mode when you install the handler.

If you are obligated to use signal(2), then your best bet is for the last thing the handler does to be to reinstall itself as the handler for the given signal (when that's in fact what you want).

Upvotes: 0

nos
nos

Reputation: 229118

Don't call main() from your signal handler, as your program is now stuck in the signal handler, and it will not call another signal handler for the same signal again while the handler is running. (That behavior can be changed if you use sigaction() instead of signal() though).

Also see what the pause() call does.

DESCRIPTION pause() causes the calling process (or thread) to sleep until a signal is delivered that either terminates the process or causes the invocation of a signal-catching function.

So, your pause(); calls waits until a signal is delivered, and then continues your program.

So, do e.g. this to keep your program running.

for(;;) {
  pause();
}

Upvotes: 1

pilcrow
pilcrow

Reputation: 58589

Whoa, don't do it that way. :)

What's happening here is that the SIGINT, for example, is masked (blocked) during the execution of the handler. So, re-invoking main from within the handler re-runs main with SIGINT blocked. Thus you see your handler fire only once per signal — it's blocked ever after. (Note that this blocking behavior is not guaranteed by signal, which is one reason you should use sigaction instead.)

The typical signal handler should do as little work as possible, using only async-signal-safe functions, if any. Think of the handler as an interruption to the ordinary flow of your process, a special asynchronous flow which can use its own stack if need be.

If you want the program to behave like a loop, code it like a loop:

static volatile sig_atomic_t flag_int;
static volatile sig_atomic_t flag_tstp;

static void handle_int(int s)  { flag_int  = 1; }  /* register me with sigaction */
static void handle_tstp(int s) { flag_tstp = 1; }  /* me, too                    */

...
  while (1) {
    pause();
    if (flag_int)  { printf("CONTROL C\n"); flag_int  = 0; }
    if (flag_tstp) { printf("CONTROL Z\n"); flag_tstp = 0; }
  }

Upvotes: 3

Related Questions