]> git.ipfire.org Git - thirdparty/util-linux.git/commitdiff
docs: kill(1): Rework notes on thread groups
authorMichael Kerrisk <mtk.manpages@gmail.com>
Mon, 5 Dec 2016 09:38:53 +0000 (10:38 +0100)
committerMichael Kerrisk <mtk.manpages@gmail.com>
Mon, 5 Dec 2016 15:51:15 +0000 (16:51 +0100)
The points in the NOTES can be expressed more compactly
(there is some redundancy in the two existing paragraphs).

Also, add a reference to signal(7), since this provides
much more detail on the topic.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
misc-utils/kill.1

index 091de407d38a0b5bb5e924421121dd0b8b4f36aa..1d7e765521e584178712def0a49e7cd2fbee2b47 100644 (file)
@@ -117,25 +117,22 @@ flag to
 then it can obtain this data via the si_sigval field of the siginfo_t structure.
 
 .SH NOTES
-It is not possible to send a signal to an explicitly selected thread in a
-multithreaded process using the
-.BR kill (2)
-system call.  If
-.BR kill (2)
-is used to send a signal to a thread group, then the kernel selects an arbitrary
-member of the thread group that has not blocked the signal.  For more details
-see
-.BR clone (2),
-the CLONE_THREAD description.
-.PP
-The command
-.BR kill (1)
-as well as system call
-.BR kill (2)
-accept a TID (thread ID, see
+Although it is possible to specify the TID (thread ID, see
 .BR gettid (2))
-as an argument.  In this case the kill behavior is not changed and the signal is
-also delivered to the thread group rather than to the specified thread.
+of one of the threads in a multithreaded process as the argument of
+.BR kill ,
+the signal is nevertheless directed to the process
+(i.e., the entire thread group).
+In other words, it is not possible to send a signal to an
+explicitly selected thread in a multithreaded process.
+The signal will be delivered to an arbitrarily selected thread
+in the target process that is not blocking the signal.
+For more details, see
+.BR signal (7)
+and the description of
+.BR CLONE_THREAD
+in
+.BR clone (2).
 
 .SH RETURN CODES
 .B kill