ALARM(3P)

💖 ALARM(3P) — bestie, it's the POSIX Programmer's Manual 💖

okay so quick vibe check before we dive in: this page lives in the POSIX Programmer's Manual, and the Linux implementation of this interface may differ — so if you're on Linux, go consult the corresponding Linux manual page for the details of Linux behavior. or like, it might not even be implemented on Linux at all. 🙈 just saying.

---

✨ NAME ✨

alarm — schedule an alarm signal. that's it. that's the whole thing. 🎀

---

🌸 SYNOPSIS 🌸

#include <unistd.h>

unsigned alarm(unsigned seconds);

---

💅 DESCRIPTION 💅

okay so alarm() makes the system generate a SIGALRM signal for the process, and it happens after the number of realtime seconds you specified in seconds have elapsed. lowkey important caveat: processor scheduling delays may prevent the process from handling the signal as soon as it is generated. so like, don't come for alarm() if it's a lil late, that's just the scheduler being the scheduler. 😭

if seconds is 0, a pending alarm request — if there is one — gets canceled. periodt.

here's the thing though: alarm requests are not stacked. only one SIGALRM generation can be scheduled in this manner, bestie. so if the SIGALRM signal has not yet been generated, the call results in rescheduling the time at which the SIGALRM signal is generated. one alarm at a time, she's monogamous. 💅

⚠️ interactions between alarm() and setitimer() are unspecified. no cap. don't mix them and expect good things.

---

👑 RETURN VALUE 👑

if there's a previous alarm() request with time remaining, alarm() returns a non-zero value — that value is the number of seconds until the previous request would have generated a SIGALRM signal. otherwise, alarm() returns 0.

---

🦋 ERRORS 🦋

alarm() is always successful, and no return value is reserved to indicate an error. she simply cannot fail, iconic behavior honestly. ✨

the following sections are informative. (so like, the lore, not the law. 📖)

---

🌈 EXAMPLES 🌈

None. — yeah bestie, there are literally none. moving on. 🧚

---

🍓 APPLICATION USAGE 🍓

• the fork() function clears pending alarms in the child process. bye alarm 👋
• a new process image created by one of the exec functions inherits the time left to an alarm signal in the image of the old process. so the clock keeps ticking, she's committed. ⏰

application developers should note that the type of the argument seconds and the return value of alarm() is unsigned. that means 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 int type, consistently use either unsigned or int. so here we are. 🤷

application developers should also be aware of possible interactions when the same process uses both the alarm() and sleep() functions. they're not enemies but they're not besties either. 😬

---

💜 RATIONALE 💜

so the lore is: 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 they do not allow them to occur early at all. that last one 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. so applications can choose the seconds argument as the minimum amount of time they wish to have elapse before the signal. it's giving "at least this long, maybe longer, never shorter." 💅

the term realtime''</hotpink> here and elsewhere (`sleep()`, `times()`) is intended to mean <hotpink>wall clock'' time as common English usage, and has nothing to do with ``realtime operating systems''. it is in contrast to virtual time, which could be misinterpreted if just time were used. iykyk. 🕰️

in some implementations, including 4.3 BSD, very large values of the seconds argument are silently rounded down to an implementation-specific maximum value. this maximum is large enough (to the order of several months) that the effect is not noticeable. so like, whatever, bestie. 😌

there were two possible choices for alarm generation in multi-threaded applications:

1. generation for the calling thread
2. 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. so yeah, thread option was giving nothing. 💀

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. and there wasn't one, so. periodt. 👑

---

⭐ FUTURE DIRECTIONS ⭐

None. — nothing coming, she's perfect as she is. 🎀

---

🔥 SEE ALSO 🔥

• alarm()
• exec
• fork()
• getitimer()
• pause()
• sigaction()
• sleep()

the Base Definitions volume of POSIX.1‐2017: <signal.h>, <unistd.h> 📚

---

💖 COPYRIGHT 💖

portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 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 .

any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. to report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

mwah 💋 that's the whole page! this icon of a manpage comes to you courtesy of IEEE/The Open Group, 2017, and yeah bestie, ALARM(3P) is the name, don't wear it out. 🫶✨