283 lines
15 KiB
HTML
283 lines
15 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content="HTML Tidy, see www.w3.org">
|
|
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
|
|
<link type="text/css" rel="stylesheet" href="style.css"><!-- Generated by The Open Group's rhtm tool v1.2.1 -->
|
|
<!-- Copyright (c) 2001 The Open Group, All Rights Reserved -->
|
|
<title>sigtimedwait</title>
|
|
</head>
|
|
<body bgcolor="white">
|
|
<script type="text/javascript" language="JavaScript" src="../jscript/codes.js">
|
|
</script>
|
|
|
|
<basefont size="3"> <a name="sigtimedwait"></a> <a name="tag_03_699"></a><!-- sigtimedwait -->
|
|
<!--header start-->
|
|
<center><font size="2">The Open Group Base Specifications Issue 6<br>
|
|
IEEE Std 1003.1-2001<br>
|
|
Copyright © 2001 The IEEE and The Open Group, All Rights reserved.</font></center>
|
|
|
|
<!--header end-->
|
|
<hr size="2" noshade>
|
|
<h4><a name="tag_03_699_01"></a>NAME</h4>
|
|
|
|
<blockquote>sigtimedwait, sigwaitinfo - wait for queued signals (<b>REALTIME</b>)</blockquote>
|
|
|
|
<h4><a name="tag_03_699_02"></a>SYNOPSIS</h4>
|
|
|
|
<blockquote class="synopsis">
|
|
<div class="box"><code><tt><sup>[<a href="javascript:open_code('RTS')">RTS</a>]</sup> <img src="../images/opt-start.gif" alt=
|
|
"[Option Start]" border="0"> #include <<a href="../basedefs/signal.h.html">signal.h</a>><br>
|
|
<br>
|
|
int sigtimedwait(const sigset_t *restrict</tt> <i>set</i><tt>,<br>
|
|
siginfo_t *restrict</tt> <i>info</i><tt>,<br>
|
|
const struct timespec *restrict</tt> <i>timeout</i><tt>);<br>
|
|
int sigwaitinfo(const sigset_t *restrict</tt> <i>set</i><tt>,<br>
|
|
siginfo_t *restrict</tt> <i>info</i><tt>); <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></tt></code></div>
|
|
|
|
<tt><br>
|
|
</tt></blockquote>
|
|
|
|
<h4><a name="tag_03_699_03"></a>DESCRIPTION</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>sigtimedwait</i>() function shall be equivalent to <i>sigwaitinfo</i>() except that if none of the signals specified by
|
|
<i>set</i> are pending, <i>sigtimedwait</i>() shall wait for the time interval specified in the <b>timespec</b> structure
|
|
referenced by <i>timeout</i>. If the <b>timespec</b> structure pointed to by <i>timeout</i> is zero-valued and if none of the
|
|
signals specified by <i>set</i> are pending, then <i>sigtimedwait</i>() shall return immediately with an error. If <i>timeout</i>
|
|
is the NULL pointer, the behavior is unspecified. <sup>[<a href="javascript:open_code('MON')">MON</a>]</sup> <img src=
|
|
"../images/opt-start.gif" alt="[Option Start]" border="0"> If the Monotonic Clock option is supported, the CLOCK_MONOTONIC
|
|
clock shall be used to measure the time interval specified by the <i>timeout</i> argument. <img src="../images/opt-end.gif" alt=
|
|
"[Option End]" border="0"></p>
|
|
|
|
<p>The <i>sigwaitinfo</i>() function selects the pending signal from the set specified by <i>set</i>. Should any of multiple
|
|
pending signals in the range SIGRTMIN to SIGRTMAX be selected, it shall be the lowest numbered one. The selection order between
|
|
realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. If no signal in <i>set</i> is
|
|
pending at the time of the call, the calling thread shall be suspended until one or more signals in <i>set</i> become pending or
|
|
until it is interrupted by an unblocked, caught signal.</p>
|
|
|
|
<p>The <i>sigwaitinfo</i>() function shall be equivalent to the <a href="../functions/sigwait.html"><i>sigwait</i>()</a> function
|
|
if the <i>info</i> argument is NULL. If the <i>info</i> argument is non-NULL, the <i>sigwaitinfo</i>() function shall be equivalent
|
|
to <a href="../functions/sigwait.html"><i>sigwait</i>()</a>, except that the selected signal number shall be stored in the
|
|
<i>si_signo</i> member, and the cause of the signal shall be stored in the <i>si_code</i> member. If any value is queued to the
|
|
selected signal, the first such queued value shall be dequeued and, if the <i>info</i> argument is non-NULL, the value shall be
|
|
stored in the <i>si_value</i> member of <i>info</i>. The system resource used to queue the signal shall be released and returned to
|
|
the system for other use. If no value is queued, the content of the <i>si_value</i> member is undefined. If no further signals are
|
|
queued for the selected signal, the pending indication for that signal shall be reset.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_04"></a>RETURN VALUE</h4>
|
|
|
|
<blockquote>
|
|
<p>Upon successful completion (that is, one of the signals specified by <i>set</i> is pending or is generated) <i>sigwaitinfo</i>()
|
|
and <i>sigtimedwait</i>() shall return the selected signal number. Otherwise, the function shall return a value of -1 and set
|
|
<i>errno</i> to indicate the error.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_05"></a>ERRORS</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>sigtimedwait</i>() function shall fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EAGAIN]</dt>
|
|
|
|
<dd>No signal specified by <i>set</i> was generated within the specified timeout period.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>sigtimedwait</i>() and <i>sigwaitinfo</i>() functions may fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EINTR]</dt>
|
|
|
|
<dd>The wait was interrupted by an unblocked, caught signal. It shall be documented in system documentation whether this error
|
|
causes these functions to fail.</dd>
|
|
</dl>
|
|
|
|
<p>The <i>sigtimedwait</i>() function may also fail if:</p>
|
|
|
|
<dl compact>
|
|
<dt>[EINVAL]</dt>
|
|
|
|
<dd>The <i>timeout</i> argument specified a <i>tv_nsec</i> value less than zero or greater than or equal to 1000 million.</dd>
|
|
</dl>
|
|
|
|
<p>An implementation only checks for this error if no signal is pending in <i>set</i> and it is necessary to wait.</p>
|
|
</blockquote>
|
|
|
|
<hr>
|
|
<div class="box"><em>The following sections are informative.</em></div>
|
|
|
|
<h4><a name="tag_03_699_06"></a>EXAMPLES</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_07"></a>APPLICATION USAGE</h4>
|
|
|
|
<blockquote>
|
|
<p>The <i>sigtimedwait</i>() function times out and returns an [EAGAIN] error. Application writers should note that this is
|
|
inconsistent with other functions such as <a href="../functions/pthread_cond_timedwait.html"><i>pthread_cond_timedwait</i>()</a>
|
|
that return [ETIMEDOUT].</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_08"></a>RATIONALE</h4>
|
|
|
|
<blockquote>
|
|
<p>Existing programming practice on realtime systems uses the ability to pause waiting for a selected set of events and handle the
|
|
first event that occurs in-line instead of in a signal-handling function. This allows applications to be written in an
|
|
event-directed style similar to a state machine. This style of programming is useful for largescale transaction processing in which
|
|
the overall throughput of an application and the ability to clearly track states are more important than the ability to minimize
|
|
the response time of individual event handling.</p>
|
|
|
|
<p>It is possible to construct a signal-waiting macro function out of the realtime signal function mechanism defined in this volume
|
|
of IEEE Std 1003.1-2001. However, such a macro has to include the definition of a generalized handler for all signals to
|
|
be waited on. A significant portion of the overhead of handler processing can be avoided if the signal-waiting function is provided
|
|
by the kernel. This volume of IEEE Std 1003.1-2001 therefore provides two signal-waiting functions-one that waits
|
|
indefinitely and one with a timeout-as part of the overall realtime signal function specification.</p>
|
|
|
|
<p>The specification of a function with a timeout allows an application to be written that can be broken out of a wait after a set
|
|
period of time if no event has occurred. It was argued that setting a timer event before the wait and recognizing the timer event
|
|
in the wait would also implement the same functionality, but at a lower performance level. Because of the performance degradation
|
|
associated with the user-level specification of a timer event and the subsequent cancelation of that timer event after the wait
|
|
completes for a valid event, and the complexity associated with handling potential race conditions associated with the user-level
|
|
method, the separate function has been included.</p>
|
|
|
|
<p>Note that the semantics of the <i>sigwaitinfo</i>() function are nearly identical to that of the <a href=
|
|
"../functions/sigwait.html"><i>sigwait</i>()</a> function defined by this volume of IEEE Std 1003.1-2001. The only
|
|
difference is that <i>sigwaitinfo</i>() returns the queued signal value in the <i>value</i> argument. The return of the queued
|
|
value is required so that applications can differentiate between multiple events queued to the same signal number.</p>
|
|
|
|
<p>The two distinct functions are being maintained because some implementations may choose to implement the POSIX Threads Extension
|
|
functions and not implement the queued signals extensions. Note, though, that <i>sigwaitinfo</i>() does not return the queued value
|
|
if the <i>value</i> argument is NULL, so the POSIX Threads Extension <a href="../functions/sigwait.html"><i>sigwait</i>()</a>
|
|
function can be implemented as a macro on <i>sigwaitinfo</i>().</p>
|
|
|
|
<p>The <i>sigtimedwait</i>() function was separated from the <i>sigwaitinfo</i>() function to address concerns regarding the
|
|
overloading of the <i>timeout</i> pointer to indicate indefinite wait (no timeout), timed wait, and immediate return, and concerns
|
|
regarding consistency with other functions where the conditional and timed waits were separate functions from the pure blocking
|
|
function. The semantics of <i>sigtimedwait</i>() are specified such that <i>sigwaitinfo</i>() could be implemented as a macro with
|
|
a NULL pointer for <i>timeout</i>.</p>
|
|
|
|
<p>The <i>sigwait</i> functions provide a synchronous mechanism for threads to wait for asynchronously-generated signals. One
|
|
important question was how many threads that are suspended in a call to a <a href="../functions/sigwait.html"><i>sigwait</i>()</a>
|
|
function for a signal should return from the call when the signal is sent. Four choices were considered:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>Return an error for multiple simultaneous calls to <i>sigwait</i> functions for the same signal.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>One or more threads return.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>All waiting threads return.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Exactly one thread returns.</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>Prohibiting multiple calls to <a href="../functions/sigwait.html"><i>sigwait</i>()</a> for the same signal was felt to be overly
|
|
restrictive. The "one or more" behavior made implementation of conforming packages easy at the expense of forcing POSIX threads
|
|
clients to protect against multiple simultaneous calls to <a href="../functions/sigwait.html"><i>sigwait</i>()</a> in application
|
|
code in order to achieve predictable behavior. There was concern that the "all waiting threads" behavior would result in "signal
|
|
broadcast storms", consuming excessive CPU resources by replicating the signals in the general case. Furthermore, no convincing
|
|
examples could be presented that delivery to all was either simpler or more powerful than delivery to one.</p>
|
|
|
|
<p>Thus, the consensus was that exactly one thread that was suspended in a call to a <i>sigwait</i> function for a signal should
|
|
return when that signal occurs. This is not an onerous restriction as:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>A multi-way signal wait can be built from the single-way wait.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Signals should only be handled by application-level code, as library routines cannot guess what the application wants to do with
|
|
signals generated for the entire process.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Applications can thus arrange for a single thread to wait for any given signal and call any needed routines upon its
|
|
arrival.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>In an application that is using signals for interprocess communication, signal processing is typically done in one place.
|
|
Alternatively, if the signal is being caught so that process cleanup can be done, the signal handler thread can call separate
|
|
process cleanup routines for each portion of the application. Since the application main line started each portion of the
|
|
application, it is at the right abstraction level to tell each portion of the application to clean up.</p>
|
|
|
|
<p>Certainly, there exist programming styles where it is logical to consider waiting for a single signal in multiple threads. A
|
|
simple <i>sigwait_multiple</i>() routine can be constructed to achieve this goal. A possible implementation would be to have each
|
|
<i>sigwait_multiple</i>() caller registered as having expressed interest in a set of signals. The caller then waits on a
|
|
thread-specific condition variable. A single server thread calls a <a href="../functions/sigwait.html"><i>sigwait</i>()</a>
|
|
function on the union of all registered signals. When the <a href="../functions/sigwait.html"><i>sigwait</i>()</a> function
|
|
returns, the appropriate state is set and condition variables are broadcast. New <i>sigwait_multiple</i>() callers may cause the
|
|
pending <a href="../functions/sigwait.html"><i>sigwait</i>()</a> call to be canceled and reissued in order to update the set of
|
|
signals being waited for.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_09"></a>FUTURE DIRECTIONS</h4>
|
|
|
|
<blockquote>
|
|
<p>None.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_10"></a>SEE ALSO</h4>
|
|
|
|
<blockquote>
|
|
<p><a href="xsh_chap02_08.html#tag_02_08_01"><i>Realtime Signals</i></a> , <a href="pause.html"><i>pause</i>()</a> , <a href=
|
|
"pthread_sigmask.html"><i>pthread_sigmask</i>()</a> , <a href="sigaction.html"><i>sigaction</i>()</a> , <a href=
|
|
"sigpending.html"><i>sigpending</i>()</a> , <a href="sigsuspend.html"><i>sigsuspend</i>()</a> , <a href=
|
|
"sigwait.html"><i>sigwait</i>()</a> , the Base Definitions volume of IEEE Std 1003.1-2001, <a href=
|
|
"../basedefs/signal.h.html"><i><signal.h></i></a>, <a href="../basedefs/time.h.html"><i><time.h></i></a></p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_11"></a>CHANGE HISTORY</h4>
|
|
|
|
<blockquote>
|
|
<p>First released in Issue 5. Included for alignment with the POSIX Realtime Extension and the POSIX Threads Extension.</p>
|
|
</blockquote>
|
|
|
|
<h4><a name="tag_03_699_12"></a>Issue 6</h4>
|
|
|
|
<blockquote>
|
|
<p>These functions are marked as part of the Realtime Signals Extension option.</p>
|
|
|
|
<p>The Open Group Corrigendum U035/3 is applied. The SYNOPSIS of the <i>sigwaitinfo</i>() function has been corrected so that the
|
|
second argument is of type <b>siginfo_t *</b>.</p>
|
|
|
|
<p>The [ENOSYS] error condition has been removed as stubs need not be provided if an implementation does not support the Realtime
|
|
Signals Extension option.</p>
|
|
|
|
<p>The DESCRIPTION is updated for alignment with IEEE Std 1003.1j-2000 by specifying that the CLOCK_MONOTONIC clock, if
|
|
supported, is used to measure timeout intervals.</p>
|
|
|
|
<p>The <b>restrict</b> keyword is added to the <i>sigtimedwait</i>() and <i>sigwaitinfo</i>() prototypes for alignment with the
|
|
ISO/IEC 9899:1999 standard.</p>
|
|
</blockquote>
|
|
|
|
<div class="box"><em>End of informative text.</em></div>
|
|
|
|
<hr>
|
|
<hr size="2" noshade>
|
|
<center><font size="2"><!--footer start-->
|
|
UNIX ® is a registered Trademark of The Open Group.<br>
|
|
POSIX ® is a registered Trademark of The IEEE.<br>
|
|
[ <a href="../mindex.html">Main Index</a> | <a href="../basedefs/contents.html">XBD</a> | <a href=
|
|
"../utilities/contents.html">XCU</a> | <a href="../functions/contents.html">XSH</a> | <a href="../xrat/contents.html">XRAT</a>
|
|
]</font></center>
|
|
|
|
<!--footer end-->
|
|
<hr size="2" noshade>
|
|
</body>
|
|
</html>
|
|
|