1ALARM(3P) POSIX Programmer's Manual ALARM(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 alarm — schedule an alarm signal
13
15 #include <unistd.h>
16 unsigned alarm(unsigned seconds);
18
20 The alarm() function shall cause the system to generate a SIGALRM sig‐
21 nal for the process after the number of realtime seconds specified by
22 seconds have elapsed. Processor scheduling delays may prevent the
23 process from handling the signal as soon as it is generated.
24 If seconds is 0, a pending alarm request, if any, is canceled.
26 Alarm requests are not stacked; only one SIGALRM generation can be
28 scheduled in this manner. If the SIGALRM signal has not yet been gener‐
29 ated, the call shall result in rescheduling the time at which the
30 SIGALRM signal is generated.
31 Interactions between alarm() and setitimer() are unspecified.
33
35 If there is a previous alarm() request with time remaining, alarm()
36 shall return a non-zero value that is the number of seconds until the
37 previous request would have generated a SIGALRM signal. Otherwise,
38 alarm() shall return 0.
39
41 The alarm() function is always successful, and no return value is
42 reserved to indicate an error.
43 The following sections are informative.
45
47 None.
48
50 The fork() function clears pending alarms in the child process. A new
51 process image created by one of the exec functions inherits the time
52 left to an alarm signal in the image of the old process.
53 Application developers should note that the type of the argument sec‐
55 onds and the return value of alarm() is unsigned. That means that a
56 Strictly Conforming POSIX System Interfaces Application cannot pass a
57 value greater than the minimum guaranteed value for {UINT_MAX}, which
58 the ISO C standard sets as 65535, and any application passing a larger
59 value is restricting its portability. A different type was considered,
60 but historical implementations, including those with a 16-bit int type,
61 consistently use either unsigned or int.
62 Application developers should be aware of possible interactions when
64 the same process uses both the alarm() and sleep() functions.
65
67 Many historical implementations (including Version 7 and System V)
68 allow an alarm to occur up to a second early. Other implementations
69 allow alarms up to half a second or one clock tick early or do not
70 allow them to occur early at all. The latter is considered most appro‐
71 priate, since it gives the most predictable behavior, especially since
72 the signal can always be delayed for an indefinite amount of time due
73 to scheduling. Applications can thus choose the seconds argument as the
74 minimum amount of time they wish to have elapse before the signal.
75 The term ``realtime'' here and elsewhere (sleep(), times()) is intended
77 to mean ``wall clock'' time as common English usage, and has nothing to
78 do with ``realtime operating systems''. It is in contrast to virtual
79 time, which could be misinterpreted if just time were used.
80 In some implementations, including 4.3 BSD, very large values of the
82 seconds argument are silently rounded down to an implementation-spe‐
83 cific maximum value. This maximum is large enough (to the order of sev‐
84 eral months) that the effect is not noticeable.
85 There were two possible choices for alarm generation in multi-threaded
87 applications: generation for the calling thread or generation for the
88 process. The first option would not have been particularly useful since
89 the alarm state is maintained on a per-process basis and the alarm that
90 is established by the last invocation of alarm() is the only one that
91 would be active.
92 Furthermore, allowing generation of an asynchronous signal for a thread
94 would have introduced an exception to the overall signal model. This
95 requires a compelling reason in order to be justified.
96
98 None.
99
101 alarm(), exec, fork(), getitimer(), pause(), sigaction(), sleep()
102 The Base Definitions volume of POSIX.1‐2017, <signal.h>, <unistd.h>
104
106 Portions of this text are reprinted and reproduced in electronic form
107 from IEEE Std 1003.1-2017, Standard for Information Technology -- Por‐
108 table Operating System Interface (POSIX), The Open Group Base Specifi‐
109 cations Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of
110 Electrical and Electronics Engineers, Inc and The Open Group. In the
111 event of any discrepancy between this version and the original IEEE and
112 The Open Group Standard, the original IEEE and The Open Group Standard
113 is the referee document. The original Standard can be obtained online
114 at http://www.opengroup.org/unix/online.html .
115 Any typographical or formatting errors that appear in this page are
117 most likely to have been introduced during the conversion of the source
118 files to man page format. To report such errors, see https://www.ker‐
119 nel.org/doc/man-pages/reporting_bugs.html .
120IEEE/The Open Group 2017 ALARM(3P)