This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Race and segmentation fault in pthread_kill() vs thread teardown

----- Original Message -----
> From: "Andreas Schwab" <>
> To: "Mathieu Desnoyers" <>
> Cc: "David Miller" <>,, "Paul E. McKenney" <>
> 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

Issue 7
  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."

Thoughts ?



> Andreas.
> --
> Andreas Schwab, SUSE Labs,
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."

Mathieu Desnoyers
EfficiOS Inc.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]