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:
Michael Kerrisk 2020-04-13 11:28:10 +02:00
parent 731192bee0
commit 3220cf5f7e
1 changed files with 18 additions and 0 deletions

View File

@ -216,6 +216,24 @@ or
.PP .PP
A process-directed signal may be delivered to any one of the A process-directed signal may be delivered to any one of the
threads that does not currently have the signal blocked. 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 If more than one of the threads has the signal unblocked, then the
kernel chooses an arbitrary thread to which to deliver the signal. kernel chooses an arbitrary thread to which to deliver the signal.
.PP .PP