Re: PL/Python fails on new NetBSD/PPC 8.0 install

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Wed, Oct 30, 2019 at 9:25 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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