Ctrl-C issue in C -Signal handling

Question

I have a question about signal handling.

Say I have two programs running at the same time. I call them program1 and program2.

I run them at separate terminal windows because one program waits for the other to start. They are designed to keep going until I hit ctrl-c in both windows. I feel this method is a bit of a hassle. So what I want to do is to add something to one of the programs.

Meaning, I can use ctrl-c to stop program1 and program2 will stop once it knows program1 is no longer active. I checked online to see if there was an example of this or some part in the C language I do know not and I came across signal handling.

I know signal handling deals with making the program do various executions depending on the signal given or how the signal is structured. Is this the right method to use or is there another way?

I saw online that using signal handling can mess up ctrl-C command in terminal if the signal is ctrl-C?

An explanation about signal handling would be much appreciated as well with some example code.

Based on the answers given, I written up a sample code according what was given:

#include <signal.h>
......
......
sigset_t SIGUSR1;
sigset_t SIGUSR2;
int signal;

void trap(int signal);
......
......
void trap(int signal)
{
int signal;
signal == SIGUSR1
}

Sorry if I look stupid for writing this but I still want to know how this works.

Answer 1

You can handle signal using header signal.h on CTRL+C is handled using SIGINT

it may work like:

   void func(int sig)
    {
    switch(sig)
    {
    case SINGINT:
    //Do whatever you want
    break;
    default :
    break;
    }
    }

    int main()
    {
    //Handle SIGINT
    signal(SIGINT,func);

    return 0;
    }

Answer 2

"or is there another way?" - here is a UNIX-slanted answer.

This topic is very broad - it is called IPC - Interprocess Communication. Cooperating processes can "talk" to each other using lots of methods, signals are just one, here are some ways:

signals
shared memory objects
sockets
message queues
files

Signals are name SIG[something], and are internally represented to the kernel as a number. kill -l will list off of the available signals and their names for you. SIGUSR1 and SIGUSR2 are meant for user applications to talk to one another. Consider using them. Don't worry about the number SIGUSR1 represents, just use the name in your code.

To use signals: On the receiving you trap a signal and set a global variable. On the sending end you call the kill() function.

SIGINT (CTRL/C) is used by the terminal to stop or interrupt running processes. So consider using SIGUSR1 and SIGUSR2 instead. By preempting SIGINT like that you will find that you may create a situation where you need to use CTRL/C. But it is trapped by your code so it has no effect. SIGUSRn does not have that problem. So you do not have to worry about competing for the use (multiple meanings) of a single signal.

Linux details: Try this link from tldp.org: http://www.advancedlinuxprogramming.com/alp-folder/alp-ch05-ipc.pdf

Edit:

prog1, the one that waits:

volatile int go=0;
void s_handler(int sig)
{
   go=1;
}


int main()
{
  signal(SIGUSR1, s_handler);
  while(go==0)
    usleep(500);
  //  run the rest of the code here when I wake up
  return 0;
}

prog2, the one that wakes up prog1 - you need the pid of prog1. pass the pid as a command line argument prog2 [pid goes here]

int main(int argc, char **argv)
{
  if(argc>1)
  {
     pid_t pid=(pid_t)atoi(argv[1]);
     if(kill(pid, 0)==0 &&  kill(pid, SIGUSR1)!=0)// check pid, then signal
     {
        perror("Can't send signal to other process");
        exit(1);
     }
  }
  // run the rest of the code here
  return 0;
}

There is no one most correct way to handle IPC. Pick one. The above uses signals.

There is no error checking just the base logic. Another way to do this is to have prog1 write the pid to a file, prog2 then reads the file, reads and uses that pid, then deletes the file. Instead of a command line argument.

You decide.