1SLEEP(3P) POSIX Programmer's Manual SLEEP(3P)
2
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 unsigned sleep(unsigned seconds);
18
21 The sleep() function shall cause the calling thread to be suspended
22 from execution until either the number of realtime seconds specified by
23 the argument seconds has elapsed or a signal is delivered to the call‐
24 ing thread and its action is to invoke a signal-catching function or to
25 terminate the process. The suspension time may be longer than requested
26 due to the scheduling of other activity by the system.
27 If a SIGALRM signal is generated for the calling process during execu‐
29 tion of sleep() and if the SIGALRM signal is being ignored or blocked
30 from delivery, it is unspecified whether sleep() returns when the
31 SIGALRM signal is scheduled. If the signal is being blocked, it is also
32 unspecified whether it remains pending after sleep() returns or it is
33 discarded.
34 If a SIGALRM signal is generated for the calling process during execu‐
36 tion of sleep(), except as a result of a prior call to alarm(), and if
37 the SIGALRM signal is not being ignored or blocked from delivery, it is
38 unspecified whether that signal has any effect other than causing
39 sleep() to return.
40 If a signal-catching function interrupts sleep() and examines or
42 changes either the time a SIGALRM is scheduled to be generated, the
43 action associated with the SIGALRM signal, or whether the SIGALRM sig‐
44 nal is blocked from delivery, the results are unspecified.
45 If a signal-catching function interrupts sleep() and calls siglongjmp()
47 or longjmp() to restore an environment saved prior to the sleep() call,
48 the action associated with the SIGALRM signal and the time at which a
49 SIGALRM signal is scheduled to be generated are unspecified. It is also
50 unspecified whether the SIGALRM signal is blocked, unless the process'
51 signal mask is restored as part of the environment.
52 Interactions between sleep() and any of setitimer(), ualarm(), or
54 usleep() are unspecified.
55
57 If sleep() returns because the requested time has elapsed, the value
58 returned shall be 0. If sleep() returns due to delivery of a signal,
59 the return value shall be the "unslept" amount (the requested time
60 minus the time actually slept) in seconds.
61
63 No errors are defined.
64 The following sections are informative.
66
68 None.
69
71 None.
72
74 There are two general approaches to the implementation of the sleep()
75 function. One is to use the alarm() function to schedule a SIGALRM sig‐
76 nal and then suspend the process waiting for that signal. The other is
77 to implement an independent facility. This volume of
78 IEEE Std 1003.1-2001 permits either approach.
79 In order to comply with the requirement that no primitive shall change
81 a process attribute unless explicitly described by this volume of
82 IEEE Std 1003.1-2001, an implementation using SIGALRM must carefully
83 take into account any SIGALRM signal scheduled by previous alarm()
84 calls, the action previously established for SIGALRM, and whether
85 SIGALRM was blocked. If a SIGALRM has been scheduled before the sleep()
86 would ordinarily complete, the sleep() must be shortened to that time
87 and a SIGALRM generated (possibly simulated by direct invocation of the
88 signal-catching function) before sleep() returns. If a SIGALRM has been
89 scheduled after the sleep() would ordinarily complete, it must be
90 rescheduled for the same time before sleep() returns. The action and
91 blocking for SIGALRM must be saved and restored.
92 Historical implementations often implement the SIGALRM-based version
94 using alarm() and pause(). One such implementation is prone to infinite
95 hangups, as described in pause(). Another such implementation uses the
96 C-language setjmp() and longjmp() functions to avoid that window. That
97 implementation introduces a different problem: when the SIGALRM signal
98 interrupts a signal-catching function installed by the user to catch a
99 different signal, the longjmp() aborts that signal-catching function.
100 An implementation based on sigprocmask(), alarm(), and sigsuspend() can
101 avoid these problems.
102 Despite all reasonable care, there are several very subtle, but
104 detectable and unavoidable, differences between the two types of imple‐
105 mentations. These are the cases mentioned in this volume of
106 IEEE Std 1003.1-2001 where some other activity relating to SIGALRM
107 takes place, and the results are stated to be unspecified. All of
108 these cases are sufficiently unusual as not to be of concern to most
109 applications.
110 See also the discussion of the term realtime in alarm() .
112 Since sleep() can be implemented using alarm(), the discussion about
114 alarms occurring early under alarm() applies to sleep() as well.
115 Application writers should note that the type of the argument seconds
117 and the return value of sleep() is unsigned. That means that a Strictly
118 Conforming POSIX System Interfaces Application cannot pass a value
119 greater than the minimum guaranteed value for {UINT_MAX}, which the
120 ISO C standard sets as 65535, and any application passing a larger
121 value is restricting its portability. A different type was considered,
122 but historical implementations, including those with a 16-bit int type,
123 consistently use either unsigned or int.
124 Scheduling delays may cause the process to return from the sleep()
126 function significantly after the requested time. In such cases, the
127 return value should be set to zero, since the formula (requested time
128 minus the time actually spent) yields a negative number and sleep()
129 returns an unsigned.
130
132 None.
133
135 alarm(), getitimer(), nanosleep(), pause(), sigaction(), sigsetjmp(),
136 ualarm(), usleep(), the Base Definitions volume of
137 IEEE Std 1003.1-2001, <unistd.h>
138
140 Portions of this text are reprinted and reproduced in electronic form
141 from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
142 -- Portable Operating System Interface (POSIX), The Open Group Base
143 Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
144 Electrical and Electronics Engineers, Inc and The Open Group. In the
145 event of any discrepancy between this version and the original IEEE and
146 The Open Group Standard, the original IEEE and The Open Group Standard
147 is the referee document. The original Standard can be obtained online
148 at http://www.opengroup.org/unix/online.html .
149IEEE/The Open Group 2003 SLEEP(3P)