The following issue has been SUBMITTED. ====================================================================== http://austingroupbugs.net/view.php?id=1214 ====================================================================== Reported By: enh Assigned To: ====================================================================== Project: 1003.1(2016)/Issue7+TC2 Issue ID: 1214 Category: System Interfaces Type: Clarification Requested Severity: Editorial Priority: normal Status: New Name: Elliott Hughes Organization: Google (Android) User Reference: Section: pthread_kill Page Number: 1657 Line Number: 54043 Interp Status: --- Final Accepted Text: ====================================================================== Date Submitted: 2018-10-03 20:43 UTC Last Modified: 2018-10-03 20:43 UTC ====================================================================== Summary: 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.) ====================================================================== 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 ======================================================================
