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 pitrou
Recipients benjamin.peterson, ncoghlan, pdox, pitrou, r.david.murray, tim.peters
Date 2017-10-01.19:25:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
Le 01/10/2017 à 21:20, 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?

On the principle yes.  I am not interested enough in this feature to
look at the implementation.

Another possibility would be to have a new separate threading API
returning a "low-level opaque thread handle" that you could pass to
pthread_kill() and pthread_getcpuclockid().  threading.get_ident() could
still be used for logging purposes and others.

A related issue: what if you want to call pthread_kill() on a non-Python

> 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
> code.

What happens for code that uses e.g. "%x" to format thread ids?
Date User Action Args
2017-10-01 19:25:55pitrousetrecipients: + pitrou, tim.peters, ncoghlan, benjamin.peterson, r.david.murray, pdox
2017-10-01 19:25:55pitroulinkissue31622 messages
2017-10-01 19:25:55pitroucreate