From 3220cf5f7ee46bfa2dd6fa178865e8fb0e6a6770 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Mon, 13 Apr 2020 11:28:10 +0200 Subject: [PATCH] signal.7: srcfix: note some implementation-specific details for process-directed signals Reported-by: Joseph C. Sible Signed-off-by: Michael Kerrisk --- man7/signal.7 | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/man7/signal.7 b/man7/signal.7 index 58618f3b8..8760d2712 100644 --- 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