WAITID(3P)

💅 WAITID(3P) 💅

bestie. sit down. hydrate. we are reading the POSIX Programmer's Manual page for WAITID(3P), and honestly? it's giving "let me lovingly spy on my children." ✨

---

🫶 PROLOG 🫶

okay so first thing, tiny disclaimer: this manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ — so if you're on Linux, go read the corresponding Linux manual page for the real tea. and also, the interface may not be implemented on Linux at all. so like. vibe check your platform first, bestie. 🫡

---

🌸 NAME 🌸

waitid — wait for a child process to change state

---

✨ SYNOPSIS ✨

#include <sys/wait.h>

int waitid(idtype_t idtype, id_t id, siginfo_t *infop, int options);

---

💖 DESCRIPTION 💖

so the waitid() function shall obtain status information (see Section 2.13, Status Information) all about termination, stop, and/or continue events happening in one of the caller's child processes. it's the group chat notification for your kids' life updates. 🦋

the waitid() function shall cause the calling thread to become blocked until an error occurs or until status information becomes available to the calling thread that satisfies all of the following properties (we call this matching status information, and yes it's the main character):

• The status information is from one of the child processes in the set of child processes specified by the idtype and id arguments.
• The state change in the status information matches one of the state change flags set in the options argument.

if matching status information is available before you even call waitid(), return shall be immediate — no waiting, we love an instant answer. 💅 if matching status information is available for two or more child processes, the order in which their status is reported is unspecified. so don't get attached to a particular order, it's not that kind of party.

as described in Section 2.13, Status Information, the waitid() function consumes the status information it obtains — unless the WNOWAIT flag is set in the options argument. (yes that's foreshadowing, keep reading.)

the behavior when multiple threads are blocked in wait(), waitid(), or waitpid() is described in Section 2.13, Status Information. go look it up if that's your situation, i'm not gonna make stuff up. 🫶

the waitid() function shall record the obtained status information in the structure pointed to by infop. the fields of the structure pointed to by infop shall be filled in as described under Pointer to a Function in Section 2.4.3, Signal Actions.

the idtype and id arguments are used to specify which children waitid() waits for. so like, pick your faves:

• if idtype is P_PID, waitid() shall wait for the child with a process ID equal to (pid_t)id.
• if idtype is P_PGID, waitid() shall wait for any child with a process group ID equal to (pid_t)id.
• if idtype is P_ALL, waitid() shall wait for any children and id is ignored.

the options argument is used to specify which state changes waitid() shall wait for. it is formed by OR'ing together the following flags — and no, you cannot skip this part, every single one matters:

• WCONTINUED — Status shall be returned for any continued child process whose status either has not been reported since it continued from a job control stop or has been reported only by calls to waitid() with the WNOWAIT flag set.
• WEXITED — Wait for processes that have exited.
• WNOHANG — Do not hang if no status is available; return immediately.
• WNOWAIT — Keep the process whose status is returned in infop in a waitable state. This shall not affect the state of the process; the process may be waited for again after this call completes.
• WSTOPPED — Status shall be returned for any child that has stopped upon receipt of a signal, and whose status either has not been reported since it stopped or has been reported only by calls to waitid() with the WNOWAIT flag set.

🚨 applications shall specify at least one of the flags WEXITED, WSTOPPED, or WCONTINUED to be OR'ed in with the options argument. that's not optional bestie, that's the law. 💀

the application shall ensure that the infop argument points to a siginfo_t structure. if waitid() returns because a child process was found that satisfied the conditions indicated by the arguments idtype and options, then the structure pointed to by infop shall be filled in by the system with the status of the process; the si_signo member shall be set equal to SIGCHLD. if waitid() returns because WNOHANG was specified and status is not available for any process specified by idtype and id, then the si_signo and si_pid members of the structure pointed to by infop shall be set to zero and the values of other members of the structure are unspecified. (unspecified = we don't talk about it, don't read into it. 🙈)

---

🌈 RETURN VALUE 🌈

• if WNOHANG was specified and status is not available for any process specified by idtype and id, 0 shall be returned.
• if waitid() returns due to the change of state of one of its children, 0 shall be returned.
• otherwise, -1 shall be returned and errno set to indicate the error.

zero, zero, or sad. that's the whole arc. 😭

---

🎀 ERRORS 🎀

the waitid() function shall fail if:

• ECHILD — The calling process has no existing unwaited-for child processes.
• EINTR — The waitid() function was interrupted by a signal.
• EINVAL — An invalid value was specified for options, or idtype and id specify an invalid set of processes.

the following sections are informative. (translation: the rest is bonus lore, not rules.) ✨

---

🍓 EXAMPLES 🍓

None.

literally nothing. no examples. the void. 🫥

---

🧚 APPLICATION USAGE 🧚

calls to waitid() with idtype equal to P_ALL will collect information about any child process. this may result in interactions with other interfaces that may be waiting for their own children (such as by use of system()). for this reason it is recommended that portable applications not use waitid() with idtype of P_ALL. see also APPLICATION USAGE for wait(). 👑

🚨 as specified in Consequences of Process Termination, if the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, then the termination of a child process will not cause status information to become available to a thread blocked in wait(), waitid(), or waitpid(). thus, a thread blocked in one of the wait functions will remain blocked unless some other condition causes the thread to resume execution (such as an [ECHILD] failure due to no remaining children in the set of waited-for children). like, forever-blocked. stuck. 💀

---

💜 RATIONALE 💜

None.

nope. nothing here either. 🫶

---

⭐ FUTURE DIRECTIONS ⭐

None.

the future is empty and honestly that's kind of peaceful. 🌸

---

🔥 SEE ALSO 🔥

• Section 2.4.3, Signal Actions
• Section 2.13, Status Information
• exec
• exit()
• wait()

the Base Definitions volume of POSIX.1‐2017:

• <signal.h>
• <sys_wait.h>

---

👑 COPYRIGHT 👑

okay this part is the legal bit and we do not editorialize the legal bit, we copy it exactly:

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 .

---

and that's the whole page bestie, WAITID(3P) by IEEE/The Open Group, 2017 — now go wait on your children responsibly, no cap. 💖✨🎀