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

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

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.