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
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