Difference between SIGUSR1 and SIGUSR2

Question

Reading the manuscript for signals, I came across the signal table and saw there are two defined signals for usr SIGUSR1 and SIGUSR2. Is there any difference between the two? If so when should I choose to use one over the other? If there is no difference why are ther two signals serving the same purpose?

Solution 1

You have two signals for your own needs. It is guaranteed that the system will never deliver them to your processes, so you can put any semantic you want on them. Why two? Purely arbitrary; only one would have certainly been stingy, so they gave us two, but they could have given much more. This is an arbitrary degree of freedom concerning signal-based communication.

I think that most of the time this is sufficient. I personally never used more than both user-defined at the same time... Such a signal is used, for example, to warn a server who is doing some consuming task that something special is to do "urgently": read something in a communication channel, stop the current task, etc. If you need more than two user-defined signals, this probably means that you made a bad design and overstrained their usage. Remember that using catching signals induces some concurrency in your own code, which has a serious impact on the design of it.

Solution 2

As far as I'm concerned there is no difference between them (beside their values). Both are reserved to the user and they must choose how to use them. They might serve the same purpose (signal something) but they can be used to signal different things.

There is a really nice example of that here. You can focus only on the signal creation and handling. Note that both SIGUSR1 and SIGUSR2 are handled by the same handler but you could give them different meanings.

Comments

[XCS]

So doing kill -USR2 <pid> will not actually kill the process, right?

[Jean-Baptiste Yunès]

@Cristy No by default signals are designed to kill the receiver (except some specific signals), and some basic semantic are attached to them to let the application behave coherently, except USR1 and USR2 for which it is guaranteed that the system will never send them by its own and there is no specific semantic attached to them.