SIGQUEUE(3P)

💌 sigqueue(3P) — the POSIX Programmer's Manual girlies know

okay so this is sigqueue(3P), straight out of the POSIX Programmer's Manual. bestie, real talk first:

⚠️ This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux.

like. the Linux girlies might do it differently, or might not show up to the party at all. check your local page. 🫶

---

🌸 NAME 🌸

sigqueue — queue a signal to a process

---

✨ SYNOPSIS ✨

#include <signal.h>

int sigqueue(pid_t pid, int signo, union sigval value);

---

💖 DESCRIPTION 💖

So basically sigqueue() takes the signal you name in signo and sends it, carrying the little payload you put in value, to the process you point at with pid. 💌

If signo is zero — that's the null signal — it still does all the error checking but doesn't actually send anything. no cap. the null signal is literally just there so you can vibe check whether pid is even valid. 👀

The conditions a process needs to have permission to queue a signal to another process? Same ones as for the kill() function. same rules, same energy.

sigqueue() returns immediately, she does not wait around. Now here's the tea:

• If SA_SIGINFO is set for signo, and the resources were actually available to queue it, then the signal shall be queued and sent to the receiving process.
• If SA_SIGINFO is not set for signo, then signo shall be sent at least once to the receiving process — but whether value gets sent along as a result of this call is unspecified. 🙈

And the plot twist nobody expects: if the value of pid causes signo to be generated for the sending process itself, and signo isn't blocked for the calling thread, and no other thread has signo unblocked or is waiting in a sigwait() function for signo — then either signo or at least the pending, unblocked signal shall be delivered to the calling thread before sigqueue() returns. she comes home to roost. 😭

Should multiple pending signals in the range SIGRTMIN to SIGRTMAX be up for delivery, the one that gets picked is the lowest numbered one. and the selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals? unspecified. we don't know her. 🤷♀️

---

🎀 RETURN VALUE 🎀

If everything slays: the specified signal shall have been queued, and sigqueue() returns a value of zero. 💅

Otherwise, she returns a value of -1 and sets errno to tell you what went wrong. 💀

---

🔥 ERRORS 🔥

sigqueue() shall fail if:

• EAGAIN — No resources are available to queue the signal. The process has already queued {SIGQUEUE_MAX} signals that are still pending at the receiver(s), or a system-wide resource limit has been exceeded. she's full, bestie, no more room. 😭
• EINVAL — The value of the signo argument is an invalid or unsupported signal number. that's not a real signal, girl. 🚫
• EPERM — The process does not have appropriate privileges to send the signal to the receiving process. not your business to send, respectfully. 🙅♀️
• ESRCH — The process pid does not exist. nobody's home. 👻

The following sections are informative.

---

🌈 EXAMPLES 🌈

None.

like. literally none. iconic of her honestly. ✨

---

🦋 APPLICATION USAGE 🦋

None.

again, nothing. we love a minimalist queen. 👑

---

💜 RATIONALE 💜

okay so WHY does sigqueue() exist, you ask? great question, bestie.

sigqueue() lets an application queue a realtime signal to itself or to another process, while specifying the application-defined value. This is common practice in realtime applications on existing realtime systems. The standard devs felt that specifying another function inside the sig... name space that was already carved out for signals was preferable to extending the interface to kill(). makes sense tbh. 🧠

This kind of function became necessary when the put/get event function of the message queues got removed. also, note this: sigqueue() implies reduced performance in a security-conscious implementation, because the access permissions between the sender and receiver have to be checked on every single send when the pid is resolved into a target process. such access checks were only necessary at message queue open in the previous interface. so. yeah. trade-offs. 💅

The standard developers required that sigqueue() have the same semantics with respect to the null signal as kill(), and that the same permission checking be used. BUT — because implementing the "broadcast" semantic of kill() is difficult (for example, to process groups) and because of the interaction with resource allocation, that semantic was not adopted. sigqueue() queues a signal to a single process specified by the pid argument. one target, one signal. no group chats. 📵

sigqueue() can fail if the system has insufficient resources to queue the signal. An explicit limit on the number of queued signals that a process could send was introduced. And here's the nuanced part: while the limit is "per-sender", this volume of POSIX.1‐2017 does not specify that the resources be part of the state of the sender. That would require either that the sender be maintained after exit until all signals it had sent to other processes were handled, or that all such signals that had not yet been acted upon be removed from the queue(s) of the receivers. This volume of POSIX.1‐2017 does not preclude this behavior — but an implementation that allocated queuing resources from a system-wide pool (with per-sender limits) and that leaves queued signals pending after the sender exits is also permitted. so it's giving "either way, we're not mad at it." 🤷♀️

---

🌟 FUTURE DIRECTIONS 🌟

None.

she's perfect, no notes, no plans to change. ⭐

---

👀 SEE ALSO 👀

• Section 2.8.1, Realtime Signals
• The Base Definitions volume of POSIX.1‐2017, <signal.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 .

---

and that's the whole page, bestie!! this absolute banger of a page is brought to you by IEEE/The Open Group, 2017, and yes the footer really does just say SIGQUEUE(3P) at the bottom like a little signature. 🫶 💖✨🎀