This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author benjamin.peterson
Recipients benjamin.peterson, ncoghlan, pdox, pitrou, r.david.murray, tim.peters
Date 2017-10-01.19:20:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
On Sun, Oct 1, 2017, at 12:15, Antoine Pitrou wrote:
> Antoine Pitrou <> added the comment:
> Le 01/10/2017 à 21:07, Benjamin Peterson a écrit :
> > 
> > signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on
> >
> Given how specialized (and of little actual use) those functions are, I
> don't think it's much of a problem if they misbehave if you deliberately
> pass an invalid thread id.

Okay, so you think this PR is reasonable?

> At least it sounds less of a problem than breaking all code that expects
> a thread id to be an integer.

I suppose, though you can't usefully use it as an integer. I imagine a
comparable and hashable opaque object would be compatible with most

> (btw, pthread_getcpuclockid returns ESRCH on Linux if called with an
> invalid thread id)

More precisely, glibc has a heuristic check for thread id validity,
which dereferences whatever you pass in. It won't save you from
Date User Action Args
2017-10-01 19:20:54benjamin.petersonsetrecipients: + benjamin.peterson, tim.peters, ncoghlan, pitrou, r.david.murray, pdox
2017-10-01 19:20:53benjamin.petersonlinkissue31622 messages
2017-10-01 19:20:53benjamin.petersoncreate