SIGQUEUE(2)

okay bestie, pull up a chair 🫶 because we're reading sigqueue(2) together — that's the sigqueue page from the System Calls Manual, section 2 energy, iykyk. It's giving realtime signal queueing and honestly? iconic. Let's get into it. 💅

---

✨ NAME ✨

sigqueue — queue a signal to a process (REALTIME)

No cap, that's the whole vibe: you're shoving a signal into somebody's queue. 🎀

---

📚 LIBRARY 📚

Standard C Library (libc, -lc)

Like, it's right there in libc, you don't have to go hunting. 🦋

---

🌸 SYNOPSIS 🌸

#include <signal.h>

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

---

💖 DESCRIPTION 💖

Okay so here's the tea. The sigqueue() system call causes the signal specified by signo to be sent with the value specified by value to the process specified by pid. Three little args, one big job. ✨

And listen — if signo is zero (that's the null signal, bestie), error checking is performed but no signal is actually sent. So it's basically a vibe check with zero follow-through 🙈. The null signal can be used to check the validity of PID. Very "not me just checking if you're still alive" energy. 💀

The conditions required for a process to have permission to queue a signal to another process are the same as for the kill(2) system call. Same rules, same gatekeeping. The sigqueue() system call queues a signal to a single process specified by the pid argument — one process, one queue, periodt.

The sigqueue() system call returns immediately. It does not sit around waiting, it is not clingy. If the resources were available to queue the signal, the signal will be queued and sent to the receiving process. 🏃‍♀️💨

Now here's the part that's lowkey a lot, so read it slow:

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() system call for signo, then either signo or at least the pending, unblocked signal will be delivered to the calling thread before sigqueue() returns.

Should any multiple pending signals in the range SIGRTMIN to SIGRTMAX be selected for delivery, it is the lowest numbered one. The selection order between realtime and non-realtime signals, or between multiple pending non-realtime signals, is unspecified. So like… don't build your whole personality on predicting that order, fr fr. 😭

---

🫶 RETURN VALUES 🫶

Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error. Classic. Iconic. The binary of it all. ✨

---

💀 ERRORS 💀

The sigqueue() system call will 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. Like babe, the queue is full, there is no room at the inn. 🙈
• [EINVAL] — The value of the signo argument is an invalid or unsupported signal number. That's not a signal, bestie, that's a typo. 💅
• [EPERM] — The process does not have the appropriate privilege to send the signal to the receiving process. Permission? Denied. Slay responsibly. 👑
• [ESRCH] — The process pid does not exist. Ghosted. Literally. 💀

---

🔥 SEE ALSO 🔥

kill(2), sigaction(2), sigpending(2), sigsuspend(2), sigtimedwait(2), sigwait(2), sigwaitinfo(2), pause(3), pthread_sigmask(3), siginfo(3)

The whole signal friend group, all linked up. Go say hi. 🦋

---

⭐ STANDARDS ⭐

The sigqueue() system call conforms to IEEE Std 1003.1-2004 (“POSIX.1”). Standards-compliant AND cute, we love to see it. ✨

---

🌈 HISTORY 🌈

Support for POSIX realtime signal queue first appeared in FreeBSD 7.0. A little historical moment, a little glow-up. 🎀

---

⚠️ CAVEATS ⚠️

Bestie, this part is important, don't skip it. 🚨

When using sigqueue to send signals to a process which might have a different ABI (for instance, one is 32-bit and the other 64-bit), the sival_int member of value can be delivered reliably, but the sival_ptr may be truncated in endian dependent ways and must not be relied on.

Further, many pointer integrity schemes disallow sending pointers to other processes, and this technique should not be used in programs intended to be portable. So like… it's giving "works on my machine" and not much else. 💀

---

and that's the whole page, you ate that 🍓 This one came to you from Debian, dated May 5, 2017 — shoutout to the maintainers, we love them for this. Now go queue a signal, you absolute main character. 💖✨🦋