Documentation/signals.txt

   1 Signals
   2 -------
   3
   4 -> Introduction
   5
   6  Signals are software interrupts. They provide a way of handling asynchronous
   7 events.
   8
   9 -> Three things to do when when a signal occurs
  10
  11  There are three different things that we can tell the kernel to do when a
  12 signal occurs. We call this the 'disposition' of the signal or the 'action'
  13 associated with a signal:
  14
  15 1. Ignore the signal (SIGKILL and SIGSTOP can't be ignored, and if we ignore
  16 signals that are generated by a hardware exception, the behaivor of the
  17 process is undefined).
  18
  19 2. Catch the signal.
  20
  21 3. Let the default action apply (for most signals the default action is to
  22 terminate the process).
  23
  24 -> Program Start-up
  25
  26  When a program is exec()ed the status of all signals is either default or
  27 ignore. Normally all signals are set to their default action, unless the
  28 process that calls exec is ignoring the signal. Specifically, the exec
  29 functions change the disposition of any signals that are being caught to
  30 their default action and leave the status of all other signals alone.
  31
  32 -> Process Creation
  33
  34 When a process calls fork the child inherits the parent's signal dispositions.
  35
  36 -> Reentrant Functions
  37
  38 There problems with some library functions when they are called from signal
  39 handlers. For example, if a process in the middle of a call to malloc() is
  40 interrupted by a signal and the signal handler also calls malloc(), the
  41 internal malloc's linked list can get corrupted (almost malloc() implementation
  42 uses linked list of memory blocks). Another problem is with functions which
  43 stores static data.
  44
  45 -> Reliable Signal Terminology and Semantics (IMPORTANTE)
  46
  47 1. A signal is _generated_ for a process (or sent to a process) when the event
  48 that causes the signal occurs.
  49
  50 2. A signal is _delivered_ to a process when the action for a signal is taken
  51
  52 3. During the time between the generation of a signal and its delivery, the
  53 signal is said to be _pending_.
  54
  55 4. A process has the option of _blocking_ the delivery of a signal. If a signal
  56 that is blocked is generated for a process, and if the action for that signal
  57 is either the default action or to catch the signal, then the signal remains
  58 pending for the process until the process either (a) unblocks the signal or
  59 (b) changes the action to ignore the signal. The system determines what to do
  60 with a blocked signal when the signal is delivered, not when it's generated.
  61
  62 5. Each process has a _signal mask_ that defines the set of signals currently
  63 blocked from delivery to that process. We can think of this mask as having one
  64 bit for each possible signal. If the bit is on for a given signal, that signal
  65 is currently blocked.
  66