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: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: gerd.moellmann <at> gmail.com, 75275 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: bug#75275: 30.0.92; `make-thread` bug on macOS 15.2
Date: Thu, 02 Jan 2025 17:31:07 +0200

> 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.

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?

Previous Next

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