This is the mail archive of the
mailing list for the glibc project.
Re: Race and segmentation fault in pthread_kill() vs thread teardown
- From: Mathieu Desnoyers <mathieu dot desnoyers at efficios dot com>
- To: Andreas Schwab <schwab at suse dot de>, Michael Kerrisk <mtk dot manpages at gmail dot com>
- Cc: David Miller <davem at davemloft dot net>, libc-alpha at sourceware dot org, "Paul E. McKenney" <paulmck at linux dot vnet dot ibm dot com>, linux-man at vger dot kernel dot org
- Date: Wed, 2 Oct 2013 12:04:40 +0000 (UTC)
- Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
- Authentication-results: sourceware.org; auth=none
- References: <305581948 dot 26980 dot 1380684877897 dot JavaMail dot zimbra at efficios dot com> <675415986 dot 27031 dot 1380686764309 dot JavaMail dot zimbra at efficios dot com> <mvm8uyc2itw dot fsf at hawking dot suse dot de>
----- Original Message -----
> From: "Andreas Schwab" <email@example.com>
> To: "Mathieu Desnoyers" <firstname.lastname@example.org>
> Cc: "David Miller" <email@example.com>, firstname.lastname@example.org, "Paul E. McKenney" <email@example.com>
> Sent: Wednesday, October 2, 2013 4:11:23 AM
> Subject: Re: Race and segmentation fault in pthread_kill() vs thread teardown
> The POSIX spec is pretty clear:
> If an application attempts to use a thread ID whose lifetime has ended,
> the behavior is undefined.
> I'd suggest to file a bug report with the Austin group wrt to the
> wording in pthread_kill.
CCing man pages maintainers,
Interestingly enough, the specification has been updated:
to remove the ESRCH return value in
Austin Group Interpretation 1003.1-2001 #142 is applied, removing the [ESRCH] error condition.
It looks like a discrepancy between the spec and the man page that causes this confusion. We might want to update pthread_kill(3), keeping ESRCH documented, but clearly marked as deprecated, and clarify that calling pthread_kill() on a non-existing thread is undefined.
We should probably remove this part entirely:
" but error checking is still perâ
formed; this can be used to check for the existence of a thread ID."
> Andreas Schwab, SUSE Labs, firstname.lastname@example.org
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."