diff options
Diffstat (limited to 'upstream/archlinux/man3p/sigqueue.3p')
| -rw-r--r-- | upstream/archlinux/man3p/sigqueue.3p | 190 |
1 files changed, 190 insertions, 0 deletions
diff --git a/upstream/archlinux/man3p/sigqueue.3p b/upstream/archlinux/man3p/sigqueue.3p new file mode 100644 index 00000000..3743dfcd --- /dev/null +++ b/upstream/archlinux/man3p/sigqueue.3p @@ -0,0 +1,190 @@ +'\" et +.TH SIGQUEUE "3P" 2017 "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, 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 \-1 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\(hy2017 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\(hy2017 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\(hy2017, +.IR "\fB<signal.h>\fP" +.\" +.SH 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 . +.PP +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 . |