queue a signal to a process (REALTIME)
Standard C Library (libc, -lc)
union sigval value
() system call causes the signal
specified by signo
to be sent with the value
specified by value
to the process specified
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 PID.
The conditions required for a process to have permission to queue a signal to
another process are the same as for the
system call. The
() system call
queues a signal to a single process specified by the
() system call returns
immediately. If the resources were available to queue the signal, the signal
will be queued and sent to the receiving process.
If the value of pid
to be generated for the sending
process, and if signo
is not blocked for the
calling thread and if no other thread has
unblocked or is waiting in a
() system call for
or at least the pending, unblocked
signal will be delivered to the calling thread before
() returns. Should any multiple
pending signals in the range
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.
Upon successful completion, the value 0 is returned; otherwise the
value -1 is returned and the global variable
is set to indicate the error.
() system call will fail if:
- No resources are available to queue the signal. The process has already
SIGQUEUE_MAX} signals that are
still pending at the receiver(s), or a system-wide resource limit has been
- The value of the signo argument is an
invalid or unsupported signal number.
- The process does not have the appropriate privilege to send the signal to
the receiving process.
- The process pid does not exist.
() system call conforms to
IEEE Std 1003.1-2004
Support for POSIX realtime signal queue first appeared in
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
can be delivered reliably, but the
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.