CODEWITHSUNDEEP
clinuxsignals
Eager-to-learn
Eager-to-learn

Reputation: 177

Signal that can be used just by my application

I am programming a tree of processes in Linux and I wonder if there is any signal that can be used just to send from A process to B process without affecting B process.

For example, assume B_pid is the process B's ID, if process A calls kill(B_pid, SIGSTOP); then A will pause B. What I am looking for is a signal, let's say SIGNOTHING, that when A calls kill(B_pid, SIGNOTHING), then it just simply sends a message to B rather than doing something to both B and the system.

Upvotes: 2

Views: 957

Answers (4)

Klaus
Klaus

Reputation: 25603

If you invoke the following command on your shell:

kill -l

you get a full list of signals available for your system.

Most of the signals can be used to simply "receive" them on the target side. BUT: Most signals are also used by the system itself to tell the application that something special happened, like SIGSEGV. So it makes no sense to use signals, which have a fixed meaning as they are used to communicate from kernel/OS to the application.

For user signals, you have two signals reserved, which can be used for everything you like: SIGUSR1 and SIGUSR2.

Not all Unix systems have these signals! So first take a look which signals can be used on your current system!

Additional hint:

Check you signal handlers and the context on which they are running. On some implementations it is not allowed to call non-reentrant functions from the context of the handler. So it is maybe more useful to communicate via a pipe or any other IPC method.

Upvotes: 1

Karthick
Karthick

Reputation: 1000

Basically each signal in Linux has a action associated with it.

Man page of signal:

   Signal dispositions
       Each signal has a current disposition, which determines how the
       process behaves when it is delivered the signal.

       The entries in the "Action" column of the table below specify the
       default disposition for each signal, as follows:

       Term   Default action is to terminate the process.

       Ign    Default action is to ignore the signal.

       Core   Default action is to terminate the process and dump core (see
              core(5)).

       Stop   Default action is to stop the process.

       Cont   Default action is to continue the process if it is currently
              stopped.

SIGSTOP

SIGSTOP      P1990      Stop    Stop process

A process can change the disposition of a signal using sigaction(2)
       or signal(2).  (The latter is less portable when establishing a
       signal handler; see signal(2) for details.)  Using these system
       calls, a process can elect one of the following behaviors to occur on
       delivery of the signal: perform the default action; ignore the
       signal; or catch the signal with a signal handler, a programmer-
       defined function that is automatically invoked when the signal is
       delivered.

You can define your own signal handler and define the behavior of your process.

Note: SIGKILL and SIGSTOP cannot be caught

Upvotes: 0

KamilCuk
KamilCuk

Reputation: 140970

There are signals that are meant for use for user programs. From man signal:

The signals SIGKILL and SIGSTOP cannot be caught, blocked, or ignored.

SIGSTOP will always stop the program and SIGKILL will always terminate the program.

There are two user-defined signals commonly used for signal communication between processes:

SIGUSR1 ... User-defined signal 1
SIGUSR2 ... User-defined signal 2

And there is also a whole range of real-time signals for use as user-defined signals between SIGRTMIN and SIGRTMAX, that have to be at least 8 signals (ie. SIGRTMAX - SIGRTMIN >= 8) and linux supports 33 signals. These are all for use for user-application to do anything it desires.

Upvotes: 1

Gereon
Gereon

Reputation: 17844

SIGUSR1 and SIGUSR2 are designed for that purpose.

Upvotes: 2

Related Questions