1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
|
.\" Copyright (c) 2001-2003 The Open Group, All Rights Reserved
.TH "ALARM" P 2003 "IEEE/The Open Group" "POSIX Programmer's Manual"
.\" alarm
.SH NAME
alarm \- schedule an alarm signal
.SH SYNOPSIS
.LP
\fB#include <unistd.h>
.br
.sp
unsigned alarm(unsigned\fP \fIseconds\fP\fB);
.br
\fP
.SH DESCRIPTION
.LP
The \fIalarm\fP() function shall cause the system to generate a SIGALRM
signal for the process after the number of realtime
seconds specified by \fIseconds\fP have elapsed. Processor scheduling
delays may prevent the process from handling the signal as
soon as it is generated.
.LP
If \fIseconds\fP is 0, a pending alarm request, if any, is canceled.
.LP
Alarm requests are not stacked; only one SIGALRM generation can be
scheduled in this manner. If the SIGALRM signal has not yet
been generated, the call shall result in rescheduling the time at
which the SIGALRM signal is generated.
.LP
Interactions between \fIalarm\fP() and any of \fIsetitimer\fP(), \fIualarm\fP(),
or \fIusleep\fP() are unspecified.
.SH RETURN VALUE
.LP
If there is a previous \fIalarm\fP() request with time remaining,
\fIalarm\fP() shall return a non-zero value that is the
number of seconds until the previous request would have generated
a SIGALRM signal. Otherwise, \fIalarm\fP() shall return 0.
.SH ERRORS
.LP
The \fIalarm\fP() function is always successful, and no return value
is reserved to indicate an error.
.LP
\fIThe following sections are informative.\fP
.SH EXAMPLES
.LP
None.
.SH APPLICATION USAGE
.LP
The \fIfork\fP() function clears pending alarms in the child process.
A new process image
created by one of the \fIexec\fP functions inherits the time left
to an alarm signal in the
old process' image.
.LP
Application writers should note that the type of the argument \fIseconds\fP
and the return value of \fIalarm\fP() is
\fBunsigned\fP. That means that a Strictly Conforming POSIX System
Interfaces Application cannot pass a value greater than the
minimum guaranteed value for {UINT_MAX}, which the ISO\ C standard
sets as 65535, and any application passing a larger value is
restricting its portability. A different type was considered, but
historical implementations, including those with a 16-bit
\fBint\fP type, consistently use either \fBunsigned\fP or \fBint\fP.
.LP
Application writers should be aware of possible interactions when
the same process uses both the \fIalarm\fP() and \fIsleep\fP() functions.
.SH RATIONALE
.LP
Many historical implementations (including Version 7 and System V)
allow an alarm to occur up to a second early. Other
implementations allow alarms up to half a second or one clock tick
early or do not allow them to occur early at all. The latter is
considered most appropriate, since it gives the most predictable behavior,
especially since the signal can always be delayed for an
indefinite amount of time due to scheduling. Applications can thus
choose the \fIseconds\fP argument as the minimum amount of time
they wish to have elapse before the signal.
.LP
The term "realtime" here and elsewhere ( \fIsleep\fP(), \fItimes\fP())
is intended to mean "wall clock" time as common English usage, and
has nothing to
do with "realtime operating systems". It is in contrast to \fIvirtual
time\fP, which could be misinterpreted if just \fItime\fP
were used.
.LP
In some implementations, including 4.3 BSD, very large values of the
\fIseconds\fP argument are silently rounded down to an
implementation-defined maximum value. This maximum is large enough
(to the order of several months) that the effect is not
noticeable.
.LP
There were two possible choices for alarm generation in multi-threaded
applications: generation for the calling thread or
generation for the process. The first option would not have been particularly
useful since the alarm state is maintained on a
per-process basis and the alarm that is established by the last invocation
of \fIalarm\fP() is the only one that would be
active.
.LP
Furthermore, allowing generation of an asynchronous signal for a thread
would have introduced an exception to the overall signal
model. This requires a compelling reason in order to be justified.
.SH FUTURE DIRECTIONS
.LP
None.
.SH SEE ALSO
.LP
alarm , \fIexec\fP() , \fIfork\fP() , \fIgetitimer\fP() , \fIpause\fP()
, \fIsigaction\fP() , \fIsleep\fP() , \fIualarm\fP()
, \fIusleep\fP() , the Base Definitions volume of IEEE\ Std\ 1003.1-2001,
\fI<signal.h>\fP, \fI<unistd.h>\fP
.SH COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 6, Copyright (C) 2001-2003 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group. In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online at
http://www.opengroup.org/unix/online.html .
|
