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

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

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> Alan Third <alan@idiocy.org> writes:
>
>> On Thu, Jan 02, 2025 at 07:22:21PM +0200, Eli Zaretskii wrote:
>>> > From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> > Cc: Alan Third <alan@idiocy.org>,  stefankangas@gmail.com,
>>> >   75275@debbugs.gnu.org
>>> > Date: Thu, 02 Jan 2025 18:09:46 +0100
>>> > 
>>> > Eli Zaretskii <eliz@gnu.org> writes:
>>> > 
>>> > >> Date: Thu, 2 Jan 2025 16:06:25 +0000
>>> > >> From: Alan Third <alan@idiocy.org>
>>> > >> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>>> > >> 	75275@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
>>> > >> 
>>> > >> On Thu, Jan 02, 2025 at 09:19:36AM -0600, Stefan Kangas wrote:
>>> > >> > That patch fixes it for me, indeed.  Thanks!
>>> > >> 
>>> > >> Hi Stefan, any chance you could check this version?
>>> > >> 
>>> > >> I have a suspicion that Gerd's will break C-g again.
>>> > >
>>> > > Did C-g work before Gerd's commit back in March?  If not, this is not
>>> > > a regression.  If it did work, can you explain how the change Gerd
>>> > > proposed now will break C-g?
>>> > 
>>> > It's different. I made the change because Emacs freezed and C-g did
>>> > nothing. With my change, Emacs freezed and I could get out with C-g, at
>>> > least sometimes.
>>> 
>>> Your change included 2 hunks, and the suggestion is to revert only
>>> one of them.  My question is whether this is likely to reintroduce
>>> some regression.
>>
>> Perhaps I'm wrong. Gerd, can you remember, did your change for C-g
>> require ns_select to run the NS runloop, or did it just require the
>> clearing out of the input queue? I'm just concerned because this
>> change will reintroduce situations where it won't run the runloop.
>>
>> The more I think about it the more I think I'm wrong...
>
> AFAIR my theory went like:
>
> - [NSApp run] + key event handler put C-g in the hold queue
>
> - ns_select_1 calls "run" (it did before my change).
>
> - I couldn't find how input events from the hold queue come
>   to Emacs in the whole process, so I added that
>
> - The "call run in all threads" was then a mistake
>
> Seemed to work, to a degree.

Maybe I should add that that is kind of a loop. It can be that the first
call to ns_select_1 has no C-g in the hold queue, NSApp.run leads to one
being put in the hold queue. A second ns_select_1 then finds C-g and
gives it Emacs and so on.

Why that whole thing hangs, is another question.