signal.7: srcfix: note some implementation-specific details for process-directed...

Reported-by: Joseph C. Sible <josephcsible@gmail.com>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

diff --git a/man7/signal.7 b/man7/signal.7
index 58618f3b83d1e4ceff553c7760191b3e04d7f8dd..8760d271220efbcdec8c2b0707e9df4ac09a8bc4 100644 (file)
--- a/man7/signal.7
+++ b/man7/signal.7
@@ -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