sigaction.html

unix 下的C开发手册,还用详细的例程。

unspecified whether the signal is discarded immediately upon
generation or remains pending.
<p>
Each thread 
has a
<i>signal mask</i>
that defines the set of signals currently blocked from delivery
to it.
The signal mask for a thread 
is initialised from that of its
parent
or creating thread, or from the corresponding thread in the parent
process if the thread was created as the result of a call to
<i><a href="fork.html">fork()</a></i>.
The
<i>sigaction()</i>,
<i><a href="sigprocmask.html">sigprocmask()</a></i>
and
<i><a href="sigsuspend.html">sigsuspend()</a></i>
functions control the manipulation of the signal mask.
<p>
The determination of which action is taken in response to a
signal is made at the time the signal is delivered, allowing for
any changes since the time of generation.
This determination is independent of the means by which the
signal was originally generated.
If a subsequent occurrence of a pending signal is generated, it
is implementation-dependent as to whether the signal is delivered
or accepted more than once in circumstances
other than those
in which queueing is required under the Realtime Signals Extension option.
The order in which multiple, simultaneously pending signals
outside the range SIGRTMIN to SIGRTMAX are delivered to or accepted by
a process is unspecified.
<p>
When any stop signal (SIGSTOP, SIGTSTP, SIGTTIN, SIGTTOU) is
generated for a process, any pending SIGCONT signals for that
process will be discarded.
Conversely, when SIGCONT is generated for a process, all pending
stop signals for that process will be discarded.
When SIGCONT is generated for a process that is stopped, the
process will be continued, even if the SIGCONT signal is blocked
or ignored.
If SIGCONT is blocked and not ignored, it will remain pending
until it is either unblocked or a stop signal is generated for
the process.
<p>
An implementation will document any condition not specified by
this document under which the implementation generates signals.
<p>
Some signal-generating functions, such as
high-resolution timer expiration,
asynchronous I/O completion, interprocess message arrival, and the
<i><a href="sigqueue.html">sigqueue()</a></i>
function,
support the specification of an application-defined value,
either explicitly as a parameter to the function or in a
<b>sigevent</b> structure parameter.
The <b>sigevent</b> structure is defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>
and contains at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>sigev_notify
<td align=left>Notification type
<tr valign=top><td align=left>int
<td align=left>sigev_signo
<td align=left>Signal number
<tr valign=top><td align=left>union sigval
<td align=left>sigev_value
<td align=left>Signal value
<tr valign=top><td align=left>void(*)(unsigned sigval)
<td align=left>sigev_notify_function
<td align=left>Notification function
<tr valign=top><td align=left>(pthread_attr_t*)
<td align=left>sigev_notify_attributes
<td align=left>Notification attributes
</table>
<p>
The 
<i>sigev_notify</i>
member specifies the notification mechanism to use
when an asynchronous event occurs.
This document defines the following values for the
<i>sigev_notify</i>
member:
<dl compact>

<dt>SIGEV_NONE<dd>
No asynchronous notification will be delivered
when the event of interest occurs.

<dt>SIGEV_SIGNAL<dd>
The signal specified in
<i>sigev_signo</i>
will be generated for the process when the event of interest occurs.
If the implementation supports the Realtime Signals Extension option
and if the SA_SIGINFO flag is set for that signal number, then the signal
will be queued to the process and the value specified in
<i>sigev_value</i>
will be the
<i>si_value</i>
component of the generated signal.
If SA_SIGINFO is not set for that signal number, it is unspecified whether
the signal is queued and what value, if any, is sent.

<dt>SIGEV_THREAD<dd>
A notification function will be called to perform notification.

</dl>
<p>
An implementation may define additional notification mechanisms.
<p>
The
<i>sigev_signo</i>
member specifies the signal to be generated.
The
<i>sigev_value</i>
member is the application-defined value
to be passed to the signal-catching function
at the time of the signal delivery
or to be returned at signal acceptance as the
<i>si_value</i>
member of the
<b>siginfo_t</b>
structure.
<p>
The
<b>sigval</b>
union is defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>
and contains at least the following members:
<p><table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>sival_int
<td align=left>Integer signal value
<tr valign=top><td align=left>void*
<td align=left>sival_ptr
<td align=left>Pointer signal value
</table>
<p>
The
<i>sival_int</i>
member is used when the application-defined value is of type
<b>int</b>;
the
<i>sival_ptr</i>
member is used when the application-defined value is a pointer.
<p>
If the Realtime Signals Extension option is supported:
<dl compact><dt> <dd>
When a signal is generated by the
<i><a href="sigqueue.html">sigqueue()</a></i>
function
or any signal-generating function that supports the specification
of an application-defined value,
the signal will be marked pending and, if the SA_SIGINFO
flag is set for that signal, the signal will be queued to the process
along with the application-specified signal value.
Multiple occurrences of signals so generated are queued in FIFO
order.
It is unspecified whether signals so generated are queued when the
SA_SIGINFO flag is not set for that signal.
<p>
Signals generated by the
<i><a href="kill.html">kill()</a></i>
function or other events that cause signals to occur,
such as detection of hardware faults,
<i><a href="alarm.html">alarm()</a></i>
timer expiration, or terminal activity,
and for which the implementation does not support queuing,
have no effect on signals already queued for the same signal
number.
</dl>
<dl compact><dt> <dd>
When multiple unblocked signals, all in the range
SIGRTMIN to SIGRTMAX, are pending,
the behaviour will be as if
the implementation delivers the pending unblocked signal
with the lowest signal number within that range.
No other ordering of signal delivery is specified.
<p>
If, when a pending signal is delivered,
there are additional signals queued to that signal number,
the signal remains pending.
Otherwise, the pending indication is reset.
</dl>
<p>
Multi-threaded programs can use an alternate event notification
mechanism:
<dl compact><dt> <dd>
When a notification is processed, and the
<i>sigev_notify</i>
member of the
<b>sigevent</b>
structure has the value SIGEV_THREAD, the function
<i>sigev_notify_function</i>
is called with parameter
<i>sigev_value</i>.
<p>
The function will be executed in an environment
as if it were the
<i>start_routine</i>
for a newly created thread with thread attributes specified by
<i>sigev_notify_attributes</i>.
If
<i>sigev_notify_attributes</i>
is NULL, the behaviour will as if the thread were created with the
<i>detachstate</i>
attribute set to PTHREAD_CREATE_DETACHED.
Supplying an attributes structure with a
<i>detachstate</i>
attribute of PTHREAD_CREATE_JOINABLE
results in undefined behaviour.
The signal mask of this thread is implementation-dependent.
</dl>
<h5><a name = "tag_000_008_581_002">&nbsp;</a>Signal Actions</h5>
<xref type="5" name="sigact"></xref>
There are three types of action that can be associated with a
signal: SIG_DFL, SIG_IGN or a
<i>pointer to a function</i>.
Initially, all signals will be set to SIG_DFL or SIG_IGN prior to
entry of the
<i>main()</i>
routine (see the
<i>exec</i>
functions).
The actions prescribed by these values are as follows:
<dl compact>

<dt>SIG_DFL - signal-specific default action<dd><ul>

<li>
The default actions for the signals defined in this specification are
specified under
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>.
If the Realtime Signals Extension option is supported,
the default actions for the realtime signals in the range SIGRTMIN to
SIGRTMAX are to terminate the process abnormally.

<li>
If the default action is to stop the process, the execution of
that process is temporarily suspended.
When a process stops, a SIGCHLD signal will be generated for its
parent process, unless the parent process has set the
SA_NOCLDSTOP flag.
While a process is stopped, any additional signals that are sent
to the process will not be delivered until the process is
continued, except SIGKILL which always terminates the receiving
process.
A process that is a member of an orphaned process group will not
be allowed to stop in response to the SIGTSTP, SIGTTIN or
SIGTTOU signals.
In cases where delivery of one of these signals would stop such a
process, the signal will be discarded.

<li>
Setting a signal action to SIG_DFL for a signal that is pending,
and whose default action is to ignore the signal (for example, SIGCHLD),
will cause the pending signal to be discarded, whether or not it
is blocked.
If the Realtime Signals Extension option is supported,
any queued values pending will be discarded and the resources used to
queue them will be released and made available to queue other signals.

</ul>

<dt>SIG_IGN - ignore signal<dd>
<ul>

<li>
Delivery of the signal will have no effect on the process.
The behaviour of a process is undefined after it ignores a
SIGFPE, SIGILL, SIGSEGV 
or SIGBUS
signal that was not generated by
<i><a href="kill.html">kill()</a></i>,
<i><a href="sigqueue.html">sigqueue()</a></i>
or
<i><a href="raise.html">raise()</a></i>.

<li>
The system will not allow the action for the signals SIGKILL or
SIGSTOP to be set to SIG_IGN.

<li>
Setting a signal action to SIG_IGN for a signal that is pending
will cause the pending signal to be discarded, whether or not it
is blocked.

<li>
If a process sets the action for the SIGCHLD signal to SIG_IGN,
the behaviour is unspecified,
except as specified below.

If the action for the SIGCHLD signal is set to SIG_IGN,
child processes of the calling processes will not be transformed into zombie
processes
when they terminate.  If the calling process subsequently waits for its
children, and the process has no unwaited for children that were transformed
into zombie processes, it will block until all of its children terminate, and
<i><a href="wait.html">wait()</a></i>,
<i><a href="wait3.html">wait3()</a></i>,
<i><a href="waitid.html">waitid()</a></i>
and
<i><a href="waitpid.html">waitpid()</a></i>
will fail and set
<i>errno</i>
to [ECHILD].

If the Realtime Signals Extension option is supported,
any queued values pending will be discarded and the resources used to
queue them will be released and made available to queue other signals.

</ul>

<dt><i>pointer to a function</i> - catch signal<dd><ul>

<li>
On delivery of the signal, the receiving process is to execute
the signal-catching function at the specified address.
After returning from the signal-catching function, the receiving
process will resume execution at the point at which it was
interrupted.

If the SA_SIGINFO
flag for the signal is cleared, the signal-catching function
will be entered as a C language function call as follows:
<pre>
<code>
void <i>func</i>(int <i>signo</i>);
</code>
</pre>
If the SA_SIGINFO flag for the signal is set, the signal-catching 
function will be entered as a C language function call as follows:
<pre>
<code>
void <i>func</i>(int <i>signo</i>, siginfo_t *<i>info</i>, void *<i>context</i>);
</code>
</pre>
where
<i>func</i>
is the specified signal-catching function,
<i>signo</i>
is the signal number of the signal being delivered, and
<i>info</i>
is a pointer to a
<b>siginfo_t</b>
structure defined in
<i><a href="signal.h.html">&lt;signal.h&gt;</a></i>
containing at least the following member(s):
<table  bordercolor=#000000 border=1 align=center><tr valign=top><th align=center><b>Member Type</b>
<th align=center><b>Member Name</b>
<th align=center><b>Description</b>
<tr valign=top><td align=left>int
<td align=left>si_signo
<td align=left>Signal number
<tr valign=top><td align=left>int
<td align=left>si_code
<td align=left>Cause of the signal
<tr valign=top><td align=left>union sigval
<td align=left>si_value
<td align=left>Signal value
</table>

The
<i>si_signo</i>
member contains the signal number.
This is the same as the
<i>signo</i>
parameter.
The
<i>si_code</i>
member contains a code identifying the cause of the signal.
The following values are defined for
<i>si_code</i>:
<dl compact>

<dt>SI_USER<dd>
The signal was sent by the
<i><a href="kill.html">kill()</a></i>
function.
The implementation may set
<i>si_code</i>
to SI_USER if the signal was sent by the
<i><a href="raise.html">raise()</a></i>
or
<i><a href="abort.html">abort()</a></i>
functions
or any similar functions provided as implementation extensions.

<dt>SI_QUEUE<dd>
The signal was sent by the
<i><a href="sigqueue.html">sigqueue()</a></i>
function.

<dt>SI_TIMER<dd>
The signal was generated by the expiration of a timer set by
<i><a href="timer_settime.html">timer_settime()</a></i>.

<dt>SI_ASYNCIO<dd>