+ * Signals are like flags: they are either active or inactive. After an
+ * external event has delivered a particular signal, it remains raised until
+ * the process acknowledges it using either sig_wait() or sig_check().
+ * Counting signals is not a reliable way to count how many times a
+ * particular event has occurred, because the same signal may be
+ * delivered twice before the process can notice.
+ *
+ * Any execution context, including an interrupt handler, can deliver
+ * a signal to a process using sig_signal(). Multiple independent signals
+ * may be delivered at once with a single invocation of sig_signal(),
+ * although this is rarely useful.
+ *
+ * \section signal_allocation Signal Allocation
+ *
+ * There's no hardcoded mapping of specific events to signal bits.
+ * The meaning of a particular signal bit is defined by an agreement
+ * between the delivering entity and the receiving process.
+ * For instance, a terminal driver may be designed to deliver
+ * a signal bit called SIG_INT when it reads the CTRL-C sequence
+ * from the keyboard, and a process may react to it by quitting.
+ *
+ * \section sig_single SIG_SINGLE
+ *
+ * The SIG_SINGLE bit is reserved as a convenient shortcut in those
+ * simple scenarios where a process needs to wait on just one event
+ * synchronously. By using SIG_SINGLE, there's no need to allocate
+ * a specific signal from the free pool. The constraints for safely
+ * accessing SIG_SINGLE are:
+ * - The process MUST sig_wait() exclusively on SIG_SINGLE
+ * - SIG_SIGNAL MUST NOT be left pending after use (sig_wait() will reset
+ * it automatically)
+ * - Do not sleep between starting the asynchronous task that will fire
+ * SIG_SINGLE, and the call to sig_wait().
+ * - Do not call system functions that may implicitly sleep, such as
+ * timer_delayTickes().
+ *
+ * \version $Id$
+ *
+ * \author Bernardo Innocenti <bernie@develer.com>