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

From: Gerd Möllmann <[email-masked]>
Date: Thu, 02 Jan 2025 18:46:25 +0100

Alan Third <[email-masked]> writes:

> On Thu, Jan 02, 2025 at 07:22:21PM +0200, Eli Zaretskii wrote:
>> > From: Gerd Möllmann <[email-masked]>
>> > Cc: Alan Third <[email-masked]>,  [email-masked],
>> >   [email-masked]
>> > Date: Thu, 02 Jan 2025 18:09:46 +0100
>> > 
>> > Eli Zaretskii <[email-masked]> writes:
>> > 
>> > >> Date: Thu, 2 Jan 2025 16:06:25 +0000
>> > >> From: Alan Third <[email-masked]>
>> > >> Cc: Gerd Möllmann <[email-masked]>,
>> > >> 	[email-masked], Eli Zaretskii <[email-masked]>
>> > >> 
>> > >> 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.