Per this comment in kernel/signal.c since time immemorial (i.e., the commit adding it is in the history repo instead of the main Linux repo): /* * 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. */ Signed-off-by: Joseph C. Sible <josephcsible@xxxxxxxxx> --- man7/signal.7 | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/man7/signal.7 b/man7/signal.7 index 0fd4f66..abf0eb8 100644 --- a/man7/signal.7 +++ b/man7/signal.7 @@ -202,10 +202,14 @@ generated as a consequence of executing a specific machine-language instruction are thread directed, as are signals targeted at a specific thread using .BR pthread_kill (3)). -A process-directed signal may be delivered to any one of the -threads that does not currently have the signal blocked. -If more than one of the threads has the signal unblocked, then the -kernel chooses an arbitrary thread to which to deliver the signal. +A process-directed signal may be delivered to any one of the threads +that does not currently have the signal blocked, according to POSIX. +On Linux, if the main thread has the signal unblocked, then the kernel +will always deliver the signal there. +.\" commit ebf5ebe31d2cd1e0f13e5b65deb0b4af7afd9dc1 +Otherwise, 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 A thread can obtain the set of signals that it currently has pending using -- 2.7.4
