xsh_chap02.html

IEEE 1003.1-2003, Single Unix Specification v3

thread.</p>
</li>
</ul>

<p>Implementations may support additional notification mechanisms by defining new values for <i>sigev_notify</i>.</p>

<p>For a notification type of SIGEV_SIGNAL, the other members of the <b>sigevent</b> structure defined by
IEEE&nbsp;Std&nbsp;1003.1-2001 specify the realtime signal-that is, the signal number and application-defined value that
differentiates between occurrences of signals with the same number-that will be generated when the event occurs. The structure is
defined in <a href="../basedefs/signal.h.html"><i>&lt;signal.h&gt;</i></a>, even though the structure is not directly used by any
of the signal functions, because it is part of the signals interface used by the POSIX.1b &quot;client functions&quot;. When the client
functions include <a href="../basedefs/signal.h.html"><i>&lt;signal.h&gt;</i></a> to define the signal names, the <b>sigevent</b>
structure will also be defined.</p>

<p>An application-defined value passed to the signal handler is used to differentiate between different &quot;events&quot; instead of
requiring that the application use different signal numbers for several reasons:</p>

<ul>
<li>
<p>Realtime applications potentially handle a very large number of different events. Requiring that implementations support a
correspondingly large number of distinct signal numbers will adversely impact the performance of signal delivery because the signal
masks to be manipulated on entry and exit to the handlers will become large.</p>
</li>

<li>
<p>Event notifications are prioritized by signal number (the rationale for this is explained in the following paragraphs) and the
use of different signal numbers to differentiate between the different event notifications overloads the signal number more than
has already been done. It also requires that the application writer make arbitrary assignments of priority to events that are
logically of equal priority.</p>
</li>
</ul>

<p>A union is defined for the application-defined value so that either an integer constant or a pointer can be portably passed to
the signal-catching function. On some architectures a pointer cannot be cast to an <b>int</b> and <i>vice versa</i>.</p>

<p>Use of a structure here with an explicit notification type discriminant rather than explicit parameters to realtime functions,
or embedded in other realtime structures, provides for future extensions to IEEE&nbsp;Std&nbsp;1003.1-2001. Additional, perhaps
more efficient, notification mechanisms can be supported for existing realtime function interfaces, such as timers and asynchronous
I/O, by extending the <b>sigevent</b> structure appropriately. The existing realtime function interfaces will not have to be
modified to use any such new notification mechanism. The revised text concerning the SIGEV_SIGNAL value makes consistent the
semantics of the members of the <b>sigevent</b> structure, particularly in the definitions of <a href=
"../functions/lio_listio.html"><i>lio_listio</i>()</a> and <a href="../functions/aio_fsync.html"><i>aio_fsync</i>()</a>. For
uniformity, other revisions cause this specification to be referred to rather than inaccurately duplicated in the descriptions of
functions and structures using the <b>sigevent</b> structure. The revised wording does not relax the requirement that the signal
number be in the range SIGRTMIN to SIGRTMAX to guarantee queuing and passing of the application value, since that requirement is
still implied by the signal names.</p>
</li>

<li>
<p>IEEE&nbsp;Std&nbsp;1003.1-2001 is intentionally vague on whether &quot;non-realtime&quot; signal-generating mechanisms can result in a
<b>siginfo_t</b> being supplied to the handler on delivery. In one existing implementation, a <b>siginfo_t</b> is posted on signal
generation, even though the implementation does not support queuing of multiple occurrences of a signal. It is not the intent of
IEEE&nbsp;Std&nbsp;1003.1-2001 to preclude this, independent of the mandate to define signals that do support queuing. Any
interpretation that appears to preclude this is a mistake in the reading or writing of the standard.</p>
</li>

<li>
<p>Signals handled by realtime signal handlers might be generated by functions or conditions that do not allow the specification of
an application-defined value and do not queue. IEEE&nbsp;Std&nbsp;1003.1-2001 specifies the <i>si_code</i> member of the
<b>siginfo_t</b> structure used in existing practice and defines additional codes so that applications can detect whether an
application-defined value is present or not. The code SI_USER for <a href="../functions/kill.html"><i>kill</i>()</a>- generated
signals is adopted from existing practice.</p>
</li>

<li>
<p>The <a href="../functions/sigaction.html"><i>sigaction</i>()</a> <i>sa_flags</i> value SA_SIGINFO tells the implementation that
the signal-catching function expects two additional arguments. When the flag is not set, a single argument, the signal number, is
passed as specified by IEEE&nbsp;Std&nbsp;1003.1-2001. Although IEEE&nbsp;Std&nbsp;1003.1-2001 does not explicitly allow the
<i>info</i> argument to the handler function to be NULL, this is existing practice. This provides for compatibility with programs
whose signal-catching functions are not prepared to accept the additional arguments. IEEE&nbsp;Std&nbsp;1003.1-2001 is explicitly
unspecified as to whether signals actually queue when SA_SIGINFO is not set for a signal, as there appear to be no benefits to
applications in specifying one behavior or another. One existing implementation queues a <b>siginfo_t</b> on each signal
generation, unless the signal is already pending, in which case the implementation discards the new <b>siginfo_t</b>; that is, the
queue length is never greater than one. This implementation only examines SA_SIGINFO on signal delivery, discarding the queued
<b>siginfo_t</b> if its delivery was not requested.</p>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001 specifies several new values for the <i>si_code</i> member of the <b>siginfo_t</b> structure. In
existing practice, a <i>si_code</i> value of less than or equal to zero indicates that the signal was generated by a process via
the <a href="../functions/kill.html"><i>kill</i>()</a> function. In existing practice, values of <i>si_code</i> that provide
additional information for implementation-generated signals, such as SIGFPE or SIGSEGV, are all positive. Thus, if implementations
define the new constants specified in IEEE&nbsp;Std&nbsp;1003.1-2001 to be negative numbers, programs written to use existing
practice will not break. IEEE&nbsp;Std&nbsp;1003.1-2001 chose not to attempt to specify existing practice values of <i>si_code</i>
other than SI_USER both because it was deemed beyond the scope of IEEE&nbsp;Std&nbsp;1003.1-2001 and because many of the values in
existing practice appear to be platform and implementation-defined. But, IEEE&nbsp;Std&nbsp;1003.1-2001 does specify that if an
implementation-for example, one that does not have existing practice in this area-chooses to define additional values for
<i>si_code</i>, these values have to be different from the values of the symbols specified by IEEE&nbsp;Std&nbsp;1003.1-2001. This
will allow conforming applications to differentiate between signals generated by one of the POSIX.1b asynchronous events and those
generated by other implementation events in a manner compatible with existing practice.</p>

<p>The unique values of <i>si_code</i> for the POSIX.1b asynchronous events have implications for implementations of, for example,
asynchronous I/O or message passing in user space library code. Such an implementation will be required to provide a hidden
interface to the signal generation mechanism that allows the library to specify the standard values of <i>si_code</i>.</p>

<p>Existing practice also defines additional members of <b>siginfo_t</b>, such as the process ID and user ID of the sending process
for <a href="../functions/kill.html"><i>kill</i>()</a>- generated signals. These members were deemed not necessary to meet the
requirements of realtime applications and are not specified by IEEE&nbsp;Std&nbsp;1003.1-2001. Neither are they precluded.</p>

<p>The third argument to the signal-catching function, <i>context</i>, is left undefined by IEEE&nbsp;Std&nbsp;1003.1-2001, but is
specified in the interface because it matches existing practice for the SA_SIGINFO flag. It was considered undesirable to require a
separate implementation for SA_SIGINFO for POSIX conformance on implementations that already support the two additional
parameters.</p>
</li>

<li>
<p>The requirement to deliver lower numbered signals in the range SIGRTMIN to SIGRTMAX first, when multiple unblocked signals are
pending, results from several considerations:</p>

<ul>
<li>
<p>A method is required to prioritize event notifications. The signal number was chosen instead of, for instance, associating a
separate priority with each request, because an implementation has to check pending signals at various points and select one for
delivery when more than one is pending. Specifying a selection order is the minimal additional semantic that will achieve
prioritized delivery. If a separate priority were to be associated with queued signals, it would be necessary for an implementation
to search all non-empty, non-blocked signal queues and select from among them the pending signal with the highest priority. This
would significantly increase the cost of and decrease the determinism of signal delivery.</p>
</li>

<li>
<p>Given the specified selection of the lowest numeric unblocked pending signal, preemptive priority signal delivery can be
achieved using signal numbers and signal masks by ensuring that the <i>sa_mask</i> for each signal number blocks all signals with a
higher numeric value.</p>

<p>For realtime applications that want to use only the newly defined realtime signal numbers without interference from the standard
signals, this can be achieved by blocking all of the standard signals in the thread signal mask and in the <i>sa_mask</i> installed
by the signal action for the realtime signal handlers.</p>
</li>
</ul>

<p>IEEE&nbsp;Std&nbsp;1003.1-2001 explicitly leaves unspecified the ordering of signals outside of the range of realtime signals
and the ordering of signals within this range with respect to those outside the range. It was believed that this would unduly
constrain implementations or standards in the future definition of new signals.</p>
</li>
</ul>

<h5><a name="tag_03_02_04_04"></a>Signal Actions</h5>

<p>Early proposals mentioned SIGCONT as a second exception to the rule that signals are not delivered to stopped processes until
continued. Because IEEE&nbsp;Std&nbsp;1003.1-2001 now specifies that SIGCONT causes the stopped process to continue when it is
generated, delivery of SIGCONT is not prevented because a process is stopped, even without an explicit exception to this rule.</p>

<p>Ignoring a signal by setting the action to SIG_IGN (or SIG_DFL for signals whose default action is to ignore) is not the same as
installing a signal-catching function that simply returns. Invoking such a function will interrupt certain system functions that
block processes (for example, <a href="../functions/wait.html"><i>wait</i>()</a>, <a href=
"../functions/sigsuspend.html"><i>sigsuspend</i>()</a>, <a href="../functions/pause.html"><i>pause</i>()</a>, <a href=
"../functions/read.html"><i>read</i>()</a>, <a href="../functions/write.html"><i>write</i>()</a>) while ignoring a signal has no
such effect on the process.</p>

<p>Historical implementations discard pending signals when the action is set to SIG_IGN. However, they do not always do the same
when the action is set to SIG_DFL and the default action is to ignore the signal. IEEE&nbsp;Std&nbsp;1003.1-2001 requires this for
the sake of consistency and also for completeness, since the only signal this applies to is SIGCHLD, and
IEEE&nbsp;Std&nbsp;1003.1-2001 disallows setting its action to SIG_IGN.</p>

<p>Some implementations (System&nbsp;V, for example) assign different semantics for SIGCLD depending on whether the action is set
to SIG_IGN or SIG_DFL. Since POSIX.1 requires that the default action for SIGCHLD be to ignore the signal, applications should
always set the action to SIG_DFL in order to avoid SIGCHLD.</p>

<p>Whether or not an implementation allows SIG_IGN as a SIGCHLD disposition to be inherited across a call to one of the <i>exec</i>
family of functions or <a href="../functions/posix_spawn.html"><i>posix_spawn</i>()</a> is explicitly left as unspecified. This
change was made as a result of IEEE PASC Interpretation 1003.1 #132, and permits the implementation to decide between the following
alternatives:</p>

<ul>
<li>
<p>Unconditionally leave SIGCHLD set to SIG_IGN, in which case the implementation would not allow applications that assume
inheritance of SIG_DFL to conform to IEEE&nbsp;Std&nbsp;1003.1-2001 without change. The implementation would, however, retain an
ability to control applications that create child processes but never call on the <i>wait</i> family of functions, potentially
filling up the process table.</p>
</li>

<li>
<p>Unconditionally reset SIGCHLD to SIG_DFL, in which case the implementation would allow applications that assume inheritance of
SIG_DFL to conform. The implementation would, however, lose an ability to control applications that spawn child processes but never
reap them.</p>
</li>

<li>
<p>Provide some mechanism, not specified in IEEE&nbsp;Std&nbsp;1003.1-2001, to control inherited SIGCHLD dispositions.</p>
</li>
</ul>

<p>Some implementations (System&nbsp;V, for example) will deliver a SIGCLD signal immediately when a process establishes a
signal-catching function for SIGCLD when that process has a child that has already terminated. Other implementations, such as 4.3
BSD, do not generate a new SIGCHLD signal in this way. In general, a process should not attempt to alter the signal action for the
SIGCHLD signal while it has any outstanding children. However, it is not always possible for a process to avoid this; for example,
shells sometimes start up processes in pipelines with other processes from the pipeline as children. Processes that cannot ensure
that they have no children when altering the signal action for SIGCHLD thus need to be prepared for, but not depend on, generation
of an immediate SIGCHLD signal.</p>

<p>The default action of the stop signals (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is to stop a process that is executing. If a stop
signal is delivered to a process that is already stopped, it has no effect. In fact, if a stop signal is generated for a stopped
process whose signal mask blocks the signal, the signal will never be delivered to the process since the process must receive a
SIGCONT, which discards all pending stop signals, in order to continue executing.</p>

<p>The SIGCONT signal continues a stopped process even if SIGCONT is blocked (or ignored). However, if a signal-catching routine
has been established for SIGCONT, it will not be entered until SIGCONT is unblocked.</p>

<p>If a process in an orphaned process group stops, it is no longer under the control of a job control shell and hence would not
normally ever be continued. Because of this, orphaned processes that receive terminal-related stop signals (SIGTSTP, SIGTTIN,
SIGTTOU, but not SIGSTOP) must not be allowed to stop. The goal is to prevent stopped processes from languishing forever. (As
SIGSTOP is sent only via <a href="../functions/kill.html"><i>kill</i>()</a>, it is assumed that the process or user sending a
SIGSTOP can send a SIGCONT when desired.) Instead, the system must discard the stop signal. As an extension, it may also deliver
another signal in its place. 4.3 BSD sends a SIGKILL, which is overly effective because SIGKILL is not catchable. Another possible
choice is SIGHUP. 4.3 BSD also does this for orphaned processes (processes whose parent has terminated) rather than for members of
orphaned process groups; this is less desirable because job control shells manage process groups. POSIX.1 also prevents SIGTTIN and
SIGTTOU signals from being generated for processes in orphaned process groups as a direct result of activity on a terminal,
preventing infinite loops when <a href="../functions/read.html"><i>read</i>()</a> and <a href=
"../functions/write.html"><i>write</i>()</a> calls generate signals that are discarded; see <a href=
"xbd_chap11.html#tag_01_11_01_04"><i>Terminal Access Control</i></a> . A similar restriction on the generation of SIGTSTP was
considered, but that would be unnecessary and more difficult to implement due