Thomas Munro <thomas.mu...@gmail.com> writes: > 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.
So I went and filed that bug, http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=54661 and the answer seems to be that netbsd's libpthread is operating as designed. They don't support creating new threads if libpthread wasn't present at main program start, so redirecting all the entry points to the libc stub functions in that case is actually pretty sane, self-consistent behavior. This behavior is actually kinda useful from our standpoint: it means that a perlu/pythonu/tclu function *can't* cause a backend to become multithreaded, even if it tries. So I definitely don't want to "fix" this by linking libpthread to the core backend; that would open us up to problems we needn't have, on this platform anyway. > 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): Yeah, this. I shall now go rant at the Python people about that. regards, tom lane
