On Wed, Oct 30, 2019 at 9:25 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> What I'm inclined to do is go file a bug report saying that this
> behavior contradicts both POSIX and NetBSD's own man page, and
> see what they say about that.
From a quick look at the relevant trees, isn't the problem here that
cpython thinks it can reserve pthread_t value -1 (or rather, that
number cast to unsigned long, which is the type it uses for its own
thread IDs):
https://github.com/python/cpython/blob/master/Include/pythread.h#L21
... and then use that to detect lack of initialisation:
https://github.com/python/cpython/blob/master/Modules/_threadmodule.c#L1149
... and that NetBSD also chose the same arbitrary value for their
threading stub library:
https://github.com/NetBSD/src/blob/trunk/lib/libc/thread-stub/thread-stub.c#L392
... as they are entirely within their rights to do? Assuming the stub
library can do whatever it has to do with that value, like answer
questions like pthread_equal(), as it clearly can. I think libc is
allowed to implement pthread_t as an integer type and reserve -1, but
application code is not allowed to assume that pthread_t is even
castable to an integer type, let alone that it can reserve magic
values.
Further evidence that this is Python's fault is the admission in the
source code itself that it is "inherently hosed":
https://github.com/python/cpython/blob/master/Python/thread_pthread.h#L299
