bug#75275: 30.0.92; `make-thread` bug on macOS 15.2

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 2 Jan 2025 11:03:50 +0000
> From: Alan Third <alan@idiocy.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com,
> 	75275@debbugs.gnu.org
> 
> > > I don't know.  Is there anything in the following code that can be
> > > relevant to a non-main thread?  Note that non-main threads can
> > > legitimately call wait_reading_process_output, which calls ns_select.
> > > For example, what happens if a non-main Lisp thread starts a
> > > sub-process? we do expect to be able to read the output from that
> > > sub-process.
> 
> My take on how this works was that in a non-main thread ns_select
> should just act like pselect, hence it used to literally just call
> pselect and return.

In general, this is not right: calls to ns_select are expected to call
thread_select, in all threads, so that other threads could get a
chance on grabbing the global lock while this (non-main) thread waits
for sub-process output.

Maybe this cannot currently work in the NS build, but then it means
any non-main thread will never relinquish the global lock until its
function returns or signals an error.

> FWIW, I still think the NS code in its current form is unsuitable for
> multi-threaded use and must be rewritten.

Then maybe we should stop supporting a with-threads build in NS?