tkill.2: srcfix: FIXME tidy-up

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-10-29 12:31:16 +02:00
parent cda56b8eed
commit eec5c0d0cc
1 changed files with 20 additions and 18 deletions

View File

@ -61,27 +61,29 @@ terminates and its thread ID is recycled.
Avoid using this system call.
.\" FIXME Maybe say something about the following:
.\" http://sourceware.org/bugzilla/show_bug.cgi?id=12889
.\" Rich Felker <bugdal@aerifal.cx>
.\" There is a race condition in pthread_kill: it is possible that,
.\" between the time pthread_kill reads the pid/tid from the target
.\" thread descriptor and the time it makes the tgkill syscall,
.\" the target thread terminates and the same tid gets assigned
.\" to a new thread in the same process.
.\"
.\" (The tgkill syscall was designed to eliminate a similar race
.\" condition in tkill, but it only succeeded in eliminating races
.\" where the tid gets reused in a different process, and does not
.\" help if the same tid gets assigned to a new thread in the
.\" same process.)
.\" Quoting Rich Felker <bugdal@aerifal.cx>:
.\"
.\" The only solution I can see is to introduce a mutex that ensures
.\" that a thread cannot exit while pthread_kill is being called on it.
.\" There is a race condition in pthread_kill: it is possible that,
.\" between the time pthread_kill reads the pid/tid from the target
.\" thread descriptor and the time it makes the tgkill syscall,
.\" the target thread terminates and the same tid gets assigned
.\" to a new thread in the same process.
.\"
.\" Note that in most real-world situations, like almost all race
.\" conditions, this one will be extremely rare. To make it
.\" measurable, one could exhaust all but 1-2 available pid values,
.\" possibly by lowering the max pid parameter in /proc, forcing
.\" the same tid to be reused rapidly.
.\" (The tgkill syscall was designed to eliminate a similar race
.\" condition in tkill, but it only succeeded in eliminating races
.\" where the tid gets reused in a different process, and does not
.\" help if the same tid gets assigned to a new thread in the
.\" same process.)
.\"
.\" The only solution I can see is to introduce a mutex that ensures
.\" that a thread cannot exit while pthread_kill is being called on it.
.\"
.\" Note that in most real-world situations, like almost all race
.\" conditions, this one will be extremely rare. To make it
.\" measurable, one could exhaust all but 1-2 available pid values,
.\" possibly by lowering the max pid parameter in /proc, forcing
.\" the same tid to be reused rapidly.
These are the raw system call interfaces, meant for internal
thread library use.