GNU bug report logs - #75275
30.0.92; `make-thread` bug on macOS 15.2

Previous Next

Full log

View this message in rfc822 format

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 75275 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>, stefankangas <at> gmail.com
Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 16:37:19 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Thu, 2 Jan 2025 11:03:50 +0000
>> From: Alan Third <alan <at> idiocy.org>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, stefankangas <at> gmail.com,
>> 	75275 <at> 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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.