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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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.

But... when I look at fd_handler, that function calls pselect directly.

          result = pselect (nfds, &readfds, wfds, NULL, tmo, NULL);


Can that be right?