'\" et
.TH SIGQUEUE "3P" 2013 "IEEE/The Open Group" "POSIX Programmer's Manual"
.SH PROLOG
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.

.SH NAME
sigqueue
\(em queue a signal to a process
.SH SYNOPSIS
.LP
.nf
#include <signal.h>
.P
int sigqueue(pid_t \fIpid\fP, int \fIsigno\fP, const union sigval \fIvalue\fP);
.fi
.SH DESCRIPTION
The
\fIsigqueue\fR()
function shall cause the signal specified by
.IR signo
to be sent with the value specified by
.IR value
to the process specified by
.IR pid .
If
.IR signo
is zero (the null signal), error checking is performed but no signal is
actually sent. The null signal can be used to check the validity of
.IR pid .
.P
The conditions required for a process to have permission to queue a
signal to another process are the same as for the
\fIkill\fR()
function.
.P
The
\fIsigqueue\fR()
function shall return immediately. If SA_SIGINFO is set for
.IR signo
and if the resources were available to queue the signal, the signal
shall be queued and sent to the receiving process. If SA_SIGINFO is not
set for
.IR signo ,
then
.IR signo
shall be sent at least once to the receiving process; it is unspecified
whether
.IR value
shall be sent to the receiving process as a result of this call.
.P
If the value of
.IR pid
causes
.IR signo
to be generated for the sending process, and if
.IR signo
is not blocked for the calling thread and if no other thread has
.IR signo
unblocked or is waiting in a
\fIsigwait\fR()
function for
.IR signo ,
either
.IR signo
or at least the pending, unblocked signal shall be delivered to the
calling thread before the
\fIsigqueue\fR()
function returns. Should any multiple pending signals in the range
SIGRTMIN to
SIGRTMAX be selected for delivery, it shall be the lowest numbered one.
The selection order between realtime and non-realtime signals, or
between multiple pending non-realtime signals, is unspecified.
.SH "RETURN VALUE"
Upon successful completion, the specified signal shall have been
queued, and the
\fIsigqueue\fR()
function shall return a value of zero. Otherwise, the function shall
return a value of \(mi1 and set
.IR errno
to indicate the error.
.SH ERRORS
The
\fIsigqueue\fR()
function shall fail if:
.TP
.BR 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.
.TP
.BR EINVAL
The value of the
.IR signo
argument is an invalid or unsupported signal number.
.TP
.BR EPERM
The process does not have appropriate privileges to send the signal
to the receiving process.
.TP
.BR ESRCH
The process
.IR pid
does not exist.
.LP
.IR "The following sections are informative."
.SH EXAMPLES
None.
.SH "APPLICATION USAGE"
None.
.SH RATIONALE
The
\fIsigqueue\fR()
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
.IR sig .\|.\|.
name space already carved out for signals was preferable to extending
the interface to
\fIkill\fR().
.P
Such a function became necessary when the put/get event function of
the message queues was removed. It should be noted that the
\fIsigqueue\fR()
function implies reduced performance in a security-conscious
implementation as the access permissions between the sender and
receiver have to be checked on each send when the
.IR pid
is resolved into a target process. Such access checks were necessary
only at message queue open in the previous interface.
.P
The standard developers required that
\fIsigqueue\fR()
have the same semantics with respect to the null signal as
\fIkill\fR(),
and that the same permission checking be used. But because of the
difficulty of implementing the ``broadcast'' semantic of
\fIkill\fR()
(for example, to process groups) and the interaction with resource
allocation, this semantic was not adopted. The
\fIsigqueue\fR()
function queues a signal to a single process specified by the
.IR pid
argument.
.P
The
\fIsigqueue\fR()
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\(hy2008 does not specify that the resources be part of the state
of the sender. This 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. This volume of POSIX.1\(hy2008 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.
.SH "FUTURE DIRECTIONS"
None.
.SH "SEE ALSO"
.IR "Section 2.8.1" ", " "Realtime Signals"
.P
The Base Definitions volume of POSIX.1\(hy2008,
.IR "\fB<signal.h>\fP"
.SH COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 7, Copyright (C) 2013 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group.
(This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) 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.unix.org/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 .