Benjamin Peterson <benja...@python.org> added the comment: On Sun, Oct 1, 2017, at 12:15, Antoine Pitrou wrote: > > Antoine Pitrou <pit...@free.fr> added the comment: > > Le 01/10/2017 à 21:07, Benjamin Peterson a écrit : > > > > signal.pthread_kill and pdox's proposed time.pthread_getcpuclockid on > > https://github.com/python/cpython/pull/3756 > > 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 code. > > (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 crashing. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31622> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
