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

[Alan Third <alan@idiocy.org>]

On Thu, Jan 02, 2025 at 06:52:11PM +0100, Gerd Möllmann wrote:
> >
> > 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.

I suspect it's because we removed the code in bug 65843.

We removed that because there was a crash on start using a specific
desktop file. Something to do with a certain amount of iconified
frames or something. It never made much sense to me, but if the
comment that went along with the code was right then sometimes the app
defined event is never delivered and therefore the event loop doesn't
stop.

I can't believe that's a genuine bug in Apple's code, because surely
they'd have fixed it by now, so probably it's something in our code,
but who knows what.

You could try reverting that change and see if it solves your hangs.
If so then we'll have to find another solution, like perhaps just
preventing ns_send_appdefined from doing anything while we're creating
frames.
-- 
Alan Third