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

[Alan Third <alan@idiocy.org>]

On Thu, Jan 02, 2025 at 04:37:19PM +0100, Gerd Möllmann wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> 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.
> 
> I think Alan meant thread_select(pselect, ...) because that's what is
> already done in ns_select_1.

Yes, sorry. What Gerd said.

> But... when I look at fd_handler, that function calls pselect directly.
> 
>           result = pselect (nfds, &readfds, wfds, NULL, tmo, NULL);
> 
> 
> Can that be right?

I think that's OK as we've already called thread_select further up.
I've a vague memory of putting this in as a work-around.

We call thread_select with a zero timeout to give other threads a
chance to grab the lock, then carry on as normal, running the run loop
and fd_handler which calls pselect.

To be fair, though, I think when we set this up I didn't understand
the code as well as I do now, so perhaps it was the wrong thing to do.
-- 
Alan Third