Austin Group Defect Tracker

Aardvark Mark III


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001214 [1003.1(2016)/Issue7+TC2] System Interfaces Editorial Clarification Requested 2018-10-03 20:43 2019-04-15 16:05
Reporter enh View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Resolved  
Name Elliott Hughes
Organization Google (Android)
User Reference
Section pthread_kill
Page Number 1657
Line Number 54043
Interp Status ---
Final Accepted Text Note: 0004362
Summary 0001214: remove claim about pthread_kill behavior when sig is 0?
Description http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_kill.html [^] says:

"As in kill(), if sig is zero, error checking shall be performed but no signal shall actually be sent."

but ESRCH isn't listed in ERRORS, only EINTR (presumably because of "Austin Group Interpretation 1003.1-2001 #142 is applied, removing the [ESRCH] error condition.").

then, later:

"A future version of this standard may require that pthread_kill() not fail with [ESRCH] in the case of sending signals to an inactive thread (a terminated thread not yet detached or joined), even though no signal will be delivered because the thread is no longer running."

which presumably should already have been removed as part of #142, since this is already the first mention of ESRCH on the page?

i'd suggest that the "As in kill()" paragraph be removed too... it makes sense for kill(2) because the argument is a pid_t, but for the most-used libc implementations (Android, iOS, and glibc) the pthread_t argument to pthread_kill(3) is basically a pointer, which means there's no safe way to implement this short of a global lock on a global thread list, which it seems unreasonable for POSIX to require.

[in Android we had so much trouble with apps causing chaos by not tracking pthread_t lifetime that we've added FORTIFY-like checking that aborts a process that hands an invalid pthread_t to any libc function. in the docs (https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o) [^] we've said "The best alternative on Android is to use pthread_gettid_np at some point that you know the thread to be alive, and then call kill/tgkill with signal 0 (which checks whether a process exists rather than actually sending a signal). That’s still not completely safe because if you're too late the tid may have been reused, but your code is inherently unsafe without a redesign anyway.".]

anyway, since POSIX currently seems to say:

1. you can pass signal 0 ...
2. but the function can't return ESRCH to tell you the thread doesn't exist
3. so your code can't portably assume the return value means anything

it seems to me that all we're doing here is confusing developers, and we should remove the "if sig is zero" paragraph?
Desired Action remove line 54043 "As in kill...".

(the "an application cannot have one thread check for termination of another with pthread_kill" [54066-54067] already supports this stance.)
Tags tc3-2008
Attached Files

- Relationships

-  Notes
(0004362)
geoffclare (manager)
2019-04-15 16:04

On page 1657 line 54043 section pthread_kill(), delete:
As in kill(), if sig is zero, error checking shall be performed but no signal shall actually be sent.

On page 1657 line 54048 section pthread_kill(), add:
The pthread_kill() function may fail if:

[EINVAL] The value of the sig argument is zero.

On page 1657 line 54049 section pthread_kill(), change:
The value of the sig argument is an invalid or unsupported signal number.
to:
The value of the sig argument is non-zero and is an invalid or unsupported signal number.

On page 1657 line 54066 section pthread_kill(), change:
In particular, this means that an application cannot have one thread check for termination of another with pthread_kill().
to:
In particular, this means that an application cannot have one thread check for termination of another by calling pthread_kill() with a sig argument of zero, and implementations may indicate that it is not possible by returning [EINVAL] when sig is zero.

- Issue History
Date Modified Username Field Change
2018-10-03 20:43 enh New Issue
2018-10-03 20:43 enh Name => Elliott Hughes
2018-10-03 20:43 enh Organization => Google (Android)
2018-10-03 20:43 enh Section => pthread_kill
2018-10-03 20:43 enh Page Number => 1657
2018-10-03 20:43 enh Line Number => 54043
2019-04-15 16:04 geoffclare Note Added: 0004362
2019-04-15 16:05 geoffclare Interp Status => ---
2019-04-15 16:05 geoffclare Final Accepted Text => Note: 0004362
2019-04-15 16:05 geoffclare Status New => Resolved
2019-04-15 16:05 geoffclare Resolution Open => Accepted As Marked
2019-04-15 16:05 geoffclare Tag Attached: tc3-2008


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker