sigwaitinfo(2)

💖 sigwaitinfo(2) — System Calls Manual 💖

okay bestie, welcome to section 2 of the manual, the one where we talk about system calls. today's main character: sigwaitinfo, and its two besties sigtimedwait and rt_sigtimedwait. they literally just sit there and wait for signals. synchronously. no cap. ✨

---

🌸 NAME 🌸

sigwaitinfo, sigtimedwait, rt_sigtimedwait — synchronously wait for queued signals 🦋

📚 LIBRARY 📚

Standard C library (libc, -lc) 🫶

✨ SYNOPSIS ✨

#include <signal.h>

int sigwaitinfo(const sigset_t *restrict set,
                siginfo_t *_Nullable restrict info);
int sigtimedwait(const sigset_t *restrict set,
                siginfo_t *_Nullable restrict info,
                const struct timespec *restrict timeout);

🎀 Feature Test Macro Requirements for glibc 🎀

(peep feature_test_macros(7) for the tea, iykyk)

sigwaitinfo(), sigtimedwait():
    _POSIX_C_SOURCE >= 199309L

💅 DESCRIPTION 💅

sigwaitinfo() suspends execution of the calling thread until one of the signals in set is pending. and like — if one of the signals in set is already pending for the calling thread, sigwaitinfo() will return immediately. no waiting required, she's ready bestie 💅

sigwaitinfo() then removes the signal from the set of pending signals and returns the signal number as its function result. and if the info argument is not NULL? then the buffer it points to gets used to return a structure of type siginfo_t (go look at sigaction(2) for the lore) containing info about the signal. cute, right?

if multiple signals in set are pending for the caller, the one that sigwaitinfo() retrieves is determined according to the usual ordering rules — see signal(7) for further details ⭐

sigtimedwait() operates in exactly the same way as sigwaitinfo() except it has an additional argument, timeout, which specifies the interval for which the thread is suspended waiting for a signal. (this interval will be rounded up to the system clock granularity, and kernel scheduling delays mean the interval may overrun by a small amount — she's not a precision instrument, she's doing her best 😭) this argument is a timespec(3) structure.

and if both fields of this structure are specified as 0, a poll is performed: sigtimedwait() returns immediately, either with information about a signal that was pending for the caller, or with an error if none of the signals in set was pending. poll queen behavior 👑

🔥 RETURN VALUE 🔥

on success, both sigwaitinfo() and sigtimedwait() return a signal number (i.e., a value greater than zero 🎉). on failure, both calls return -1, with errno set to indicate the error. sad girl era 💀

⚠️ ERRORS ⚠️

• EAGAIN — no signal in set became pending within the timeout period specified to sigtimedwait(). she waited, nobody came, it's giving ghosted 🥲
• EINTR — the wait was interrupted by a signal handler; see signal(7). (this handler was for a signal other than one of those in set.) like, rude much?
• EINVAL — timeout was invalid. nope. not that. 🙈

🌈 VERSIONS 🌈

🧚 C library/kernel differences 🧚

on Linux, sigwaitinfo() is a library function implemented on top of sigtimedwait(). nested girlies ✨

the glibc wrapper functions for sigwaitinfo() and sigtimedwait() silently ignore attempts to wait for the two real-time signals that are used internally by the NPTL threading implementation. see nptl(7) for details — that's a whole other episode fr fr.

the original Linux system call was named sigtimedwait(). however, with the addition of real-time signals in Linux 2.2, the fixed-size, 32-bit sigset_t type supported by that system call was no longer fit for purpose. so consequently, a new system call, rt_sigtimedwait(), was added to support an enlarged sigset_t type. 👑

this new system call takes a fourth argument, size_t sigsetsize, which specifies the size in bytes of the signal set in set. this argument is currently required to have the value sizeof(sigset_t) (or the error EINVAL results — yes, the error from before, she's back 😭). the glibc sigtimedwait() wrapper function hides these details from us, transparently calling rt_sigtimedwait() when the kernel provides it. she's a secret keeper. iconic.

📜 STANDARDS 📜

POSIX.1-2024. periodt 💅

🕰️ HISTORY 🕰️

POSIX.1-2001. vintage, but make it functional 🎀

🩷 NOTES 🩷

• in normal usage, the calling program blocks the signals in set via a prior call to sigprocmask(2) — so that the default disposition for these signals does not occur if they become pending between successive calls to sigwaitinfo() or sigtimedwait() — and does not establish handlers for these signals. basically: block first, ask questions later. in a multithreaded program, the signal should be blocked in all threads, in order to prevent the signal being treated according to its default disposition in a thread other than the one calling sigwaitinfo() or sigtimedwait(). 👀
• the set of signals that is pending for a given thread is the union of the set of signals that is pending specifically for that thread and the set of signals that is pending for the process as a whole (see signal(7)). math but make it signals ✨
• attempts to wait for SIGKILL and SIGSTOP are silently ignored. like she didn't even hear you. 🫥
• if multiple threads of a process are blocked waiting for the same signal(s) in sigwaitinfo() or sigtimedwait(), then exactly one of the threads will actually receive the signal if it becomes pending for the process as a whole; which of the threads receives the signal is indeterminate. mystery handoff, no receipts 💀
• sigwaitinfo() or sigtimedwait() can't be used to receive signals that are synchronously generated, such as the SIGSEGV signal that results from accessing an invalid memory address, or the SIGFPE signal that results from an arithmetic error. such signals can be caught only via signal handler. no shortcuts bestie, that's the rule 😤
• POSIX leaves the meaning of a NULL value for the timeout argument of sigtimedwait() unspecified, permitting the possibility that this has the same meaning as a call to sigwaitinfo(), and indeed this is what is done on Linux. undefined-but-actually-defined, the Linux special 🌸

👀 SEE ALSO 👀

kill(2), sigaction(2), signal(2), signalfd(2), sigpending(2), sigprocmask(2), sigqueue(3), sigsetops(3), sigwait(3), timespec(3), signal(7), time(7)

---

and that's the whole page bestie!! this one came to you from Linux man-pages 6.20, dated 2026-02-08, and it's all about sigwaitinfo(2) 💖 go block some signals, stay hydrated, and remember: only one thread gets the signal. mwah 🫶✨