On Wed, Oct 30, 2019 at 9:25 AM Tom Lane <t...@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
