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:34:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1506886447.3585953.1124266472.6BD036B1@webmail.messagingengine.com>
In-reply-to <4ebc3b0d-aaa0-117d-136b-a01affb13d63@free.fr>
Content
On Sun, Oct 1, 2017, at 12:25, Antoine Pitrou wrote:
> 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
> thread?

C code that provides pthread_t to Python would have to wrap it.

> 
> > 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?

It's okay for the opaque object to have a int() conversion. The
important part is that threading apis don't accept ints.
History
Date User Action Args
2017-10-01 19:34:10benjamin.petersonsetrecipients: + benjamin.peterson, tim.peters, ncoghlan, pitrou, r.david.murray, pdox
2017-10-01 19:34:10benjamin.petersonlinkissue31622 messages
2017-10-01 19:34:10benjamin.petersoncreate