mirror of https://github.com/mkerrisk/man-pages
signal.7: srcfix: note some implementation-specific details for process-directed signals
Reported-by: Joseph C. Sible <josephcsible@gmail.com> Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
731192bee0
commit
3220cf5f7e
|
@ -216,6 +216,24 @@ or
|
|||
.PP
|
||||
A process-directed signal may be delivered to any one of the
|
||||
threads that does not currently have the signal blocked.
|
||||
.\" Joseph C. Sible notes:
|
||||
.\" On Linux, if the main thread has the signal unblocked, then the kernel
|
||||
.\" will always deliver the signal there, citing this kernel code
|
||||
.\"
|
||||
.\" Per this comment in kernel/signal.c since time immemorial:
|
||||
.\"
|
||||
.\" /*
|
||||
.\" * Now find a thread we can wake up to take the signal off the queue.
|
||||
.\" *
|
||||
.\" * If the main thread wants the signal, it gets first crack.
|
||||
.\" * Probably the least surprising to the average bear.
|
||||
.\" */
|
||||
.\"
|
||||
.\" But this does not mean the signal will be delivered only in the
|
||||
.\" main thread, since if a handler is already executing in the main thread
|
||||
.\" (and thus the signal is blocked in that thread), then a further
|
||||
.\" might be delivered in a different thread.
|
||||
.\"
|
||||
If more than one of the threads has the signal unblocked, then the
|
||||
kernel chooses an arbitrary thread to which to deliver the signal.
|
||||
.PP
|
||||
|
|
Loading…
Reference in New Issue