SIGQUEUE(3POSIX)

💌 SIGQUEUE(3POSIX) — the POSIX Programmer's Manual, bestie edition 💌

Okay so first things first, before we get into the ✨lore✨: this page is part of the POSIX Programmer's Manual, and there's a whole PROLOG situation you need to know about. The Linux implementation of this interface may differ — so like, go check the corresponding Linux manual page for the deets on Linux behavior, okay? Or honestly? It might not even be implemented on Linux at all. It's giving "your mileage may vary." 🙈

---

🎀 NAME 🎀

sigqueue — queue a signal to a process

---

🌸 SYNOPSIS 🌸

#include <signal.h>

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

---

✨ DESCRIPTION ✨

So the sigqueue() function shall cause the signal specified by signo to be sent with the value specified by value to the process specified by pid. Sending a whole little care package, fr fr. 💅

If signo is zero (that's the null signal, bestie), error checking gets done but no signal is actually sent. It's a vibe check and nothing more — the null signal can be used to check the validity of pid. No signal, just gossip. 🫖

The conditions required for a process to have permission to queue a signal to another process are the same as for the kill() function. Same rules, different function, iykyk.

The sigqueue() function shall return immediately. Like, it does not wait around. 🏃‍♀️

• If SA_SIGINFO is set for signo and if the resources were available to queue the signal, the signal shall be queued and sent to the receiving process. Iconic, it actually delivers.
• If SA_SIGINFO is not set for signo, then signo shall be sent at least once to the receiving process. And lowkey? It is unspecified whether value shall be sent to the receiving process as a result of this call. So the value might just ghost. 😭

Now here's the fun part. If the value of pid causes signo to be generated for the sending process, and if signo is not blocked for the calling thread, and if 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 the sigqueue() function returns. No sneaky delays, periodt.

Should any multiple pending signals in the range SIGRTMIN to SIGRTMAX be selected for delivery, it shall be the lowest numbered one. First come, first served, but make it numeric. 🔢

The selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. Yeah bestie, that one's just vibes-based and the standard refuses to comment. 💀

---

👑 RETURN VALUE 👑

Upon successful completion, the specified signal shall have been queued, and the sigqueue() function shall return a value of zero. Slay. 🎉

Otherwise, the function shall return a value of -1 and set errno to indicate the error. Not slay. 😔

---

🔥 ERRORS 🔥

The sigqueue() function 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. Bestie is full, no more signals, the queue said "I'm at capacity, respectfully." 🚫
• 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. Permission denied, you don't have the ✨credentials✨.
• ESRCH — The process pid does not exist. It's not there. It never was. It's giving ghost town. 👻

The following sections are informative. (Fancy way of saying "not the legally binding part," bestie.)

---

🌈 EXAMPLES 🌈

None.

(Yeah, they really just wrote "None." The audacity. 💀)

---

🦋 APPLICATION USAGE 🦋

None.

(Again. Nothing. Empty. A whole section with nothing in it. Not me expecting content. 😭)

---

💜 RATIONALE 💜

Okay so the why of it all. The sigqueue() function allows an application to queue a realtime signal to itself or to another process, specifying the application-defined value. This is common practice in realtime applications on existing realtime systems. It was felt that specifying another function in the sig... name space already carved out for signals was preferable to extending the interface to kill(). Like, stay in your lane, kill(). 💅

Such a function became necessary when the put/get event function of the message queues was removed. Rip to that function, you will be missed. 🕯️

And now, a warning-ish note: it should be noted that the sigqueue() function implies reduced performance in a security-conscious implementation, because the access permissions between the sender and receiver have to be checked on each send when the pid is resolved into a target process. Such access checks were necessary only at message queue open in the previous interface. So yeah, security costs you speed, that's the tradeoff, no cap. 🐢

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 of the difficulty of implementing the "broadcast" semantic of kill() (for example, to process groups) and the interaction with resource allocation, this semantic was not adopted. So no broadcasting, bestie. sigqueue() queues a signal to a single process specified by the pid argument. One process, one signal, one vibe. 🎯

The sigqueue() function 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. 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. Why? Because that would require either that the sender be maintained after exit until all signals that 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. And 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 like, both options are valid. The standard said "I'm not picking sides." 🤷‍♀️

---

🧚 FUTURE DIRECTIONS 🧚

None.

(Third empty section. They're really committed to the minimalism aesthetic. 💀)

---

⭐ 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 icon of a manual page is brought to you by IEEE/The Open Group, 2017 — yes, the footer really does just say that, and yes, you read the whole thing, and yes, you're basically a realtime signals expert now. Go queue something (responsibly). 💖✨🎀🦋🌸💅