|Anonymous | Login||2020-09-29 23:08 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001214||[1003.1(2016/18)/Issue7+TC2] System Interfaces||Editorial||Clarification Requested||2018-10-03 20:43||2019-11-12 15:44|
|Priority||normal||Resolution||Accepted As Marked|
|Final Accepted Text||Note: 0004362|
|Summary||0001214: remove claim about pthread_kill behavior when sig is 0?|
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.").
"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?
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.)
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:
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.
|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|
|2019-11-12 15:44||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|