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 2018-10-03 20:43
Reporter enh View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Elliott Hughes
Organization Google (Android)
User Reference
Section pthread_kill
Page Number 1657
Line Number 54043
Interp Status ---
Final Accepted Text
Summary 0001214: remove claim about pthread_kill behavior when sig is 0?
Description [^] 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 ( [^] 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 No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- 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

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