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

From: Gerd Möllmann <[email-masked]>
Date: Thu, 02 Jan 2025 16:37:19 +0100

Eli Zaretskii <[email-masked]> writes:

>> Date: Thu, 2 Jan 2025 11:03:50 +0000
>> From: Alan Third <[email-masked]>
>> Cc: Eli Zaretskii <[email-masked]>, [email-masked],
>> 	[email-masked]
>> 
>> > > 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?