1SLEEP(3P) POSIX Programmer's Manual SLEEP(3P)
2
3
4
6 This manual page is part of the POSIX Programmer's Manual. The Linux
7 implementation of this interface may differ (consult the corresponding
8 Linux manual page for details of Linux behavior), or the interface may
9 not be implemented on Linux.
10
12 sleep — suspend execution for an interval of time
13
15 #include <unistd.h>
16
17 unsigned sleep(unsigned seconds);
18
20 The sleep() function shall cause the calling thread to be suspended
21 from execution until either the number of realtime seconds specified by
22 the argument seconds has elapsed or a signal is delivered to the call‐
23 ing thread and its action is to invoke a signal-catching function or to
24 terminate the process. The suspension time may be longer than requested
25 due to the scheduling of other activity by the system.
26
27 In single-threaded programs, sleep() may make use of SIGALRM. In multi-
28 threaded programs, sleep() shall not make use of SIGALRM and the
29 remainder of this DESCRIPTION does not apply.
30
31 If a SIGALRM signal is generated for the calling process during execu‐
32 tion of sleep() and if the SIGALRM signal is being ignored or blocked
33 from delivery, it is unspecified whether sleep() returns when the
34 SIGALRM signal is scheduled. If the signal is being blocked, it is also
35 unspecified whether it remains pending after sleep() returns or it is
36 discarded.
37
38 If a SIGALRM signal is generated for the calling process during execu‐
39 tion of sleep(), except as a result of a prior call to alarm(), and if
40 the SIGALRM signal is not being ignored or blocked from delivery, it is
41 unspecified whether that signal has any effect other than causing
42 sleep() to return.
43
44 If a signal-catching function interrupts sleep() and examines or
45 changes either the time a SIGALRM is scheduled to be generated, the
46 action associated with the SIGALRM signal, or whether the SIGALRM sig‐
47 nal is blocked from delivery, the results are unspecified.
48
49 If a signal-catching function interrupts sleep() and calls siglongjmp()
50 or longjmp() to restore an environment saved prior to the sleep() call,
51 the action associated with the SIGALRM signal and the time at which a
52 SIGALRM signal is scheduled to be generated are unspecified. It is
53 also unspecified whether the SIGALRM signal is blocked, unless the sig‐
54 nal mask of the process is restored as part of the environment.
55
56 Interactions between sleep() and setitimer() are unspecified.
57
59 If sleep() returns because the requested time has elapsed, the value
60 returned shall be 0. If sleep() returns due to delivery of a signal,
61 the return value shall be the ``unslept'' amount (the requested time
62 minus the time actually slept) in seconds.
63
65 No errors are defined.
66
67 The following sections are informative.
68
70 None.
71
73 None.
74
76 There are two general approaches to the implementation of the sleep()
77 function. One is to use the alarm() function to schedule a SIGALRM sig‐
78 nal and then suspend the calling thread waiting for that signal. The
79 other is to implement an independent facility. This volume of
80 POSIX.1‐2017 permits either approach in single-threaded programs, but
81 the simple alarm/suspend implementation is not appropriate for multi-
82 threaded programs.
83
84 In order to comply with the requirement that no primitive shall change
85 a process attribute unless explicitly described by this volume of
86 POSIX.1‐2017, an implementation using SIGALRM must carefully take into
87 account any SIGALRM signal scheduled by previous alarm() calls, the
88 action previously established for SIGALRM, and whether SIGALRM was
89 blocked. If a SIGALRM has been scheduled before the sleep() would ordi‐
90 narily complete, the sleep() must be shortened to that time and a
91 SIGALRM generated (possibly simulated by direct invocation of the sig‐
92 nal-catching function) before sleep() returns. If a SIGALRM has been
93 scheduled after the sleep() would ordinarily complete, it must be
94 rescheduled for the same time before sleep() returns. The action and
95 blocking for SIGALRM must be saved and restored.
96
97 Historical implementations often implement the SIGALRM-based version
98 using alarm() and pause(). One such implementation is prone to infi‐
99 nite hangups, as described in pause(). Another such implementation
100 uses the C-language setjmp() and longjmp() functions to avoid that win‐
101 dow. That implementation introduces a different problem: when the
102 SIGALRM signal interrupts a signal-catching function installed by the
103 user to catch a different signal, the longjmp() aborts that signal-
104 catching function. An implementation based on sigprocmask(), alarm(),
105 and sigsuspend() can avoid these problems.
106
107 Despite all reasonable care, there are several very subtle, but
108 detectable and unavoidable, differences between the two types of imple‐
109 mentations. These are the cases mentioned in this volume of
110 POSIX.1‐2017 where some other activity relating to SIGALRM takes place,
111 and the results are stated to be unspecified. All of these cases are
112 sufficiently unusual as not to be of concern to most applications.
113
114 See also the discussion of the term realtime in alarm().
115
116 Since sleep() can be implemented using alarm(), the discussion about
117 alarms occurring early under alarm() applies to sleep() as well.
118
119 Application developers should note that the type of the argument sec‐
120 onds and the return value of sleep() is unsigned. That means that a
121 Strictly Conforming POSIX System Interfaces Application cannot pass a
122 value greater than the minimum guaranteed value for {UINT_MAX}, which
123 the ISO C standard sets as 65535, and any application passing a larger
124 value is restricting its portability. A different type was considered,
125 but historical implementations, including those with a 16-bit int type,
126 consistently use either unsigned or int.
127
128 Scheduling delays may cause the process to return from the sleep()
129 function significantly after the requested time. In such cases, the
130 return value should be set to zero, since the formula (requested time
131 minus the time actually spent) yields a negative number and sleep()
132 returns an unsigned.
133
135 A future version of this standard may require that sleep() does not
136 make use of SIGALRM in all programs, not just multi-threaded programs.
137
139 alarm(), getitimer(), nanosleep(), pause(), sigaction(), sigsetjmp()
140
141 The Base Definitions volume of POSIX.1‐2017, <unistd.h>
142
144 Portions of this text are reprinted and reproduced in electronic form
145 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
146 table Operating System Interface (POSIX), The Open Group Base Specifi‐
147 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
148 Electrical and Electronics Engineers, Inc and The Open Group. In the
149 event of any discrepancy between this version and the original IEEE and
150 The Open Group Standard, the original IEEE and The Open Group Standard
151 is the referee document. The original Standard can be obtained online
152 at http://www.opengroup.org/unix/online.html .
153
154 Any typographical or formatting errors that appear in this page are
155 most likely to have been introduced during the conversion of the source
156 files to man page format. To report such errors, see https://www.ker‐
157 nel.org/doc/man-pages/reporting_bugs.html .
158
159
160
161IEEE/The Open Group 2017 SLEEP(3P)