Re: igc, macOS avoiding signals

[Pip Cet]

"Eli Zaretskii" <eliz@gnu.org> writes:

>> Date: Tue, 31 Dec 2024 10:09:25 +0000
>> From: Pip Cet <pipcet@protonmail.com>
>> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>, Eli Zaretskii <eliz@gnu.org>, 
>> spd@toadstyle.org, emacs-devel@gnu.org
>>
>> "Helmut Eller" <eller.helmut@gmail.com> writes:
>>
>> > I wonder if the backtrace that we see in the signal handler is any
>> > different from the backrace that we would see at the next safe point
>> > (i.e. the next time maybe_quit is called).
>>
>> If we keep a shadow signal mask, the only requirement for a safe point
>> is that we made some progress OR the lock was released.  But the
>> backtrace will change if we wait for the next maybe_quit, IIUC.
>>
>> maybe_quit is not a great safe point, it's just the best we have.  It's
>> insufficient if Emacs becomes idle, and how often we call rarely_quit
>> is quite unpredictable.
>
> What about doing that from process_pending_signals?

Yes.  The rest of this email is a half-hearted defense of why I didn't
do that right away.

We certainly want to call it from unblock_to if the count reaches (I
think that's what you meant?), but I wasn't convinced we wouldn't need a
shadow signal mask for that.

Merging the pending_signals flag in keyboard.c and the one in igc.c (if
that's what you meant) sounds like a good idea, too, but needs some more
thought: if we handle some signals while input is blocked, but not
others, what should pending_signals be?

Anyway, I'm perfectly willing to give up on the "no shadow mask"
assumption.  Maybe it'll help us catch some signal bugs on weird
platforms if we use it when --enable-checking --with-mps=no.

Pip