bug#72496: 31.0.50; macOS: freezes without beach ball

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

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

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>>> Cc: 72496@debbugs.gnu.org
>>>> Date: Tue, 06 Aug 2024 18:36:39 +0200
>>>> 
>>>> I've tried this
>>>> 
>>>>   (when (fboundp 'ns-app-stop)
>>>>     (defun sigusr1-handler ()
>>>>       (interactive)
>>>>       (message "SIGUSR1 - stop event loop")
>>>>       (ns-app-stop))
>>>>     (keymap-set special-event-map "<sigusr1>" 'sigusr1-handler))
>>>> 
>>>> where ns-app-stop does such a ns_send_appdefined, but that didn't work
>>>> for a reason unknown to me.
>>>
>>> Maybe the way SIGUSR1 is handled involves the same event queue that is
>>> botched in this scenario?
>>
>> Yes, that's quite likely. I had a little hope that a signal would maybe
>> handled in some special way, but apparently not.
>
> I'm now running locally with the attached change. This removes the
> global variable that can prevent sending app-defined events when set
> wrong. Instead, I'm using [NSApplication nextEventMatchingMask] to check
> if an app-defined event has already been posted. This is infinelty less
> dangerous.
>
> Let's see if that is the problem.

I don't even know if this is related to my change to ns_send_appdefined, but
I got a freeze today while using child frames (vertico + posframe) that
I haven't seen before. Event the mouse behaved strangely on the whole
macOS until I killed the process. That was without beach ball.

So, whatever that was, my patch at least didn't help, if it wasn't
causing it.

I give up. I'll switch to using tty Emacs.