Hi Joseph, On 9/13/18 5:26 AM, Joseph C. Sible wrote: > 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 Thanks for the patch, but I am reluctant to document this too explicitly, since it is an implementations detail that is likely different on other systems, and could change on Linux in the future (and was I presume different before 2.6.0). I think user-space applications should not be relying on it. Furthermore, documenting this as you suggest would give users the wrong idea about what happens. I mean: suppose that the signal was delivered to the main thread, where a handler was currently executing. In that case, if a second signal arrived, then it would be handled in another thread, because at the moment the main thread is blocking the signal. (I've tested this, to be sure of it.) Your text might instead lead people to conclude that the signal would *always* be delivered only in the main thread, which is not the case. I've instead just noted some details as a comment in the page source. Thanks, Michael 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 -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
