ALARM(P) ALARM(P)
NAME
alarm - schedule an alarm signal
SYNOPSIS
#include <unistd.h>
unsigned alarm(unsigned seconds);
DESCRIPTION
The alarm() function shall cause the system to generate a SIGALRM signal for the process
after the number of realtime seconds specified by seconds have elapsed. Processor schedul-
ing delays may prevent the process from handling the signal as soon as it is generated.
If seconds is 0, a pending alarm request, if any, is canceled.
Alarm requests are not stacked; only one SIGALRM generation can be scheduled in this man-
ner. If the SIGALRM signal has not yet been generated, the call shall result in reschedul-
ing the time at which the SIGALRM signal is generated.
Interactions between alarm() and any of setitimer(), ualarm(), or usleep() are unspeci-
fied.
RETURN VALUE
If there is a previous alarm() request with time remaining, alarm() shall return a non-
zero value that is the number of seconds until the previous request would have generated a
SIGALRM signal. Otherwise, alarm() shall return 0.
ERRORS
The alarm() function is always successful, and no return value is reserved to indicate an
error.
The following sections are informative.
EXAMPLES
None.
APPLICATION USAGE
The fork() function clears pending alarms in the child process. A new process image cre-
ated by one of the exec functions inherits the time left to an alarm signal in the old
process' image.
Application writers should note that the type of the argument seconds and the return value
of alarm() is unsigned. 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 implementa-
tions, including those with a 16-bit int type, consistently use either unsigned or int.
Application writers should be aware of possible interactions when the same process uses
both the alarm() and sleep() functions.
RATIONALE
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 seconds argument as the minimum amount of time they wish to have elapse
before the signal.
The term "realtime" here and elsewhere ( sleep(), times()) is intended to mean "wall
clock" time as common English usage, and has nothing to do with "realtime operating sys-
tems". It is in contrast to virtual time, which could be misinterpreted if just time were
used.
In some implementations, including 4.3 BSD, very large values of the seconds 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.
There were two possible choices for alarm generation in multi-threaded applications: gen-
eration 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 alarm() is the only one that
would be active.
Furthermore, allowing generation of an asynchronous signal for a thread would have intro-
duced an exception to the overall signal model. This requires a compelling reason in order
to be justified.
FUTURE DIRECTIONS
None.
SEE ALSO
alarm , exec() , fork() , getitimer() , pause() , sigaction() , sleep() , ualarm() ,
usleep() , the Base Definitions volume of IEEE Std 1003.1-2001, <signal.h>, <unistd.h>
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 orig-
inal Standard can be obtained online at http://www.opengroup.org/unix/online.html .
POSIX 2003 ALARM(P)
|