Singals - A system programmer's perspective

First things first.
1. You raise a signal - i.e - Send a signal.
2. You catch a signal -i.e- Your signal handler handles the signal.

Well most people like to define signals as software interrupts. I'm not even going into that muddle.
But it's the most erroneous definition possible. First of all, software interrupts are different entities and are quite different. Signals though have some similarities with interrupts.

Signals are events within the Linux/Unix system which causes your registered handler to be called.
If you don't have a handler registered, your program is going to get killed. That's all.

But yes, signals can be largely looked as software entities. A process can send signal to another process.

SIGKILL Kill (can’t be caught or ignored.)
SIGSTOP Stop executing. (Can’t be caught or ignored.)

Well, as you can see, the above two signals are special.

1// signal () - It's the call which registers your signal handler with the OS.
As you can expect, it takes two arguments.
arg 1 - signal num - The signal number for which you want the hadler to respond.
arg 2 - The signal hadler function pointer.

2//kill() - This is the function which is used to send a signal to a process.
As you can expect, it also takes two parameters.
param 1 - pid - pid of the process to which to send the signal.
param 2 - sig num - The signal number.

3// alarm () - This is a functionality which is used to schedule a signal after specified number of
seconds. The signal received is always SIGALRM.

However simple signal() interface might look, it's not now-a-days used by programmers.
People prefer sigaction() now-a-days.

My next post would deal with sigaction because it's a topic by itself.